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PREFACE 

This manual is written for customer systems programmers, DEC Software 
Specialists, and internal maintenance programmers. Readers must be 
familiar with the XVM/DOS Users Manual. In addition. Chapter 9 re- 
quires familiarity with the BOSS XVM User's Manual. 



IX 



CHAPTER 1 
INTRODUCTION 

XVM/DOS is a disk-based, single-user interactive operating system for 
the XVM and PDP-15 computers. This manual describes the internal oper- 
ation of principle components of XVM/DOS. In addition it describes 
certain programming techniques of interest to system programmers. 

Chapter 2 describes miscellaneous advanced system programming features, 
Chapter 8 describes how to write an I/O driver. These two chapters 
contain the most commonly used information in this manual. The rest 
of the manual describes the internal operation of various portions of 
XVM/DOS . 

Chapters 3, 4, and 5 describe the resident monitor, the nonresident 
monitor, and the system loader respectively. Chapter 6 describes var- 
ious blocks, tables, and other data structures used within XVM/DOS. 
Chapter 7 describes the formats of DECtape, magtape, and disk file 
structures. Chapter 9 describes BOSS mode and non-BOSS Batch mode. 
The information in these chapters is intended primarily for informa- 
tional purposes. It would be of immediate use only if the user were 
to modify XVM/DOS. 
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CHAPTER 2 
ADVANCED PROGRAMMING FEATURES 

This chapter describes those XVM/DOS features of interest to system 
programmers. These features are difficult to use, and may negatively 
affect system performance and integrity if used incorrectly. For this 
reason, and also since they are used infrequently, these features are 
described here rather than in the XVM/DOS Users Manual. 

Many of the features described in this chapter make use of the system 
communication table .SCOM. All .SCOM locations have mnemonics defined 
for them, and should only be referenced using these mnemonics. The 
programming examples included in this chapter follow this convention, 
first equating the mnemonic to the appropriate value and then using 
the mnemonic whenever the .SCOM location is accessed. This convention 
makes programs more readable and future alterations of .SCOM easier. 

As stated previously, many of the features described herein may nega- 
tively affect system integrity if used incorrectly. The example coding 
sequences provided herein are especially sensitive in this regard. 
Many of the coding sequences contain timing and order dependencies, 
especially in their interactions with interrupt routines. For this 
reason the coding sequences presented here should be followed exactly, 
especially with respect to the order in which operations are performed. 
The programmer must be especially cautious when, as is normally the 
case, he does not completely understand th'e internal operation of the 
particular feature he is using. 

2.1 TIMING FEATURES 

XVM/DOS provides several timing mechanisms for user programs. .TIMER 
is capable of scheduling routines for execution at a specified time. 
(See Section 2.2.) Job time limits are provided for both BOSS and 
non-BOSS modes of operations. BOSS time limits are part of the $JOB 
card (described in BOSS XVM User's Manual), whereas non-BOSS time limits 
are accomplished by the TIMEST command (described in XVM/DOS User's 
Manual) . All other timing features are described below. 
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2.1.1 Time of Day (SC.TIM) 



The current time of day is maintained in .SCOM location SC.TIM. Its 
format is: 



SC.TIM 



£ 



5.6 



11 



hours 

' ' ' L 



minutes 
-I I I i_ 



12 



17 



seconds 

I I I L. 



Time is kept according to a 24 hour clock. 

SC.TIM should always be accessed using the mnemonic SC.TIM, after first 
equating SC.TIM to 150g. SC.TIM is location 150 in memory. 

The time of day is set to 00:00:00 (midnight) following a cold-start. 
The time may subsequently be reset with the TIME command (described in 
XVM/DOS User's Manual). 

2.1.2 Calendar Date (SC.DAY) 

The current date is maintained in .SCOM location SC.DAY. Its format 
is: 



SC.DAY 



J? 



5,6 



11,12 



17 I 



month 

J ! ' ' » 



day 

J ! ' ' ' 



year 

J ! ! ! L, 



The year is stored as years since 19 70; thus, zero corresponds to 19 70. 
The month is stored as the calendar month; one corresponds to January. 
The day is merely the date within the month. Note that neither the 
month nor the day field may legitimately be zero, except in the case 
described below. 

SC.DAY should always be accessed using the mnemonic SC.DAY, after first 
equating SC.DAY to 147g. SC.DAY is location 147 in memory. 

Following a cold-start, SC.DAY is cleared to zero, indicating the 
current date is unknown. If the current date is unknown, the non- 
resident monitor will, upon being invoked, ask the user for the date. 
The date is also set unknown (SC.DAY cleared) whenever midnight is 
reached twice in succession without the non-resident monitor having 
been invoked in between. 
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2.1.3 Interval Timing (SC.ETT) 

.SCOM location SC.ETT is provided for interval timing by user programs. 
It is incremented either 50 or 60 times per second, depending upon 
the line frequency. This location is not used by any system program. 
The user may modify this location freely. 

SC.ETT should always be accessed using the mnemonic SC.ETT, after first 

equating SC.ETT to ISl^. SC.ETT is location 151 in memory. 

o 

2.2 TIMER INTERRUPT ROUTINES 

The .TIMER CAL allows the user to schedule .TIMER interrupt routines 
for execution at a specified time. This section describes the coding 
conventions which must be followed when writing a .TIMER interrupt 
routine. Use of the .TIMER CAL itself and its associated system macro 
are described in the XVM/DOS User's Manual. 

The XVM/DOS monitor invokes .TIMER interrupt routines by simulating 
a JMS instruction. The high three bits (the operating mode bits) of 
the return address may differ, however, from the bits which would be 
stored by an actual JMS. When the user program is in XVM mode (17 bit 
addressing mode) these high three bits will always be zero. When the 
user program is not in XVM mode, the contents of these bits are un- 
defined. 

When the .TIMER interrupt routine is entered, the state of the user 
program AC, Link, Bank/Page mode status, and XVM mode status are pre- 
served so a return to the interrupted code is possible. However, 
modifying one of the registers or states and returning (from the 
.TIMER routine) will not always alter the corresponding register or 
state for the interrupted user program. 
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There are three forms which a .TIMER interrupt routine might take. 
These forms are: 

1. Routines which do not return to the interrupted code. 
This form should be avoided whenever API might not be 
used. 

2. Routines which return to the interrupted code without 
scheduling a new .TIMER interrupt. 

3. Routines which return to the interrupted code after 
scheduling a new .TIMER interrupt. 

The three sections which follow describe the coding conventions appro- 
priate to each form of .TIMER interrupt routine. Following this is a 
section covering the hazards of using .TIMER without also using API. 

2.2.1 Routines Which Do Not Return 

A .TIMER interrupt routine which will not return to the interrupted 
code should be coded as follows: 



timint 

JMP label 



No state information need be preserved since the interrupted code will 
not be resumed. However, any I/O in progress may need to be aborted. 

WARNING 

System integrity cannot be guaranteed if this 
form is used without API. In particular, disk 
file structures ma'^^ be corrupted. It is stroncrlv 
recommended that all .TIMER interrupt routines 
return to the interrupted code (possibly after 
setting appropriate flags) if the program might 
ever be used without API. 

2.2.2 Routines Which Return 

A .TIMER interrupt routine which will return to the interrupted code 
should be coded as follows: 



2-4 



timint j? 

DAC saveac 

RAR 

DAC savlnk 



/ Save AC 
/ and Link. 



LAC savlnk 

RAL 

LAC saveac 

JMP* timint 



/ Restore Link 

/ and AC 

/ and return. 



The user is responsible for saving and restoring the AC and Link. The 
user must also preserve all other registers and states , including the 
index and limit registers, EAE registers, auto- increment registers, FPP 
registers, and XVM mode (17 bit addressing mode) status. The .TIMER 
interrupt routine must not call any non-re-entrant user routines nor 
use any CAL ' s . 

These restrictions may be relaxed somewhat if the .TIMER interrupt 
routine will only be used when API is also in use. If this assumption 
holds, the interrupt routine may issue CAL's freely. However, it is 
necessary to ensure that the mainstream program and the interrupt 
routine do not interfere with each other's .DAT slots. If API will 
be used, the interrupt routine may also make free use of any registers 
which are not used by the mainstream program. See Section 2.2.4 for a 
more detailed discussion of .TIMER restrictions when API might not be 
used. 

2.2.3 Routines Which Re-Schedule and Return 

A .TIMER interrupt routine which will schedule a new .TIMER interrupt 
and then return to the interrupted code should be coded as follows : 



.INH=705522 
.ENB=705521 
SC.TMA=161 
SC.TMT=160 

timint 

DAC saveac 

RAR 

DAC savlnk 



/ Save AC 

/ ... and Link, 



LAC (address) 
DAC* (SC.TMA) 

.INH 
lOF 



/ Put address of next .TIMER 
/ Interrupt routine in SC.TMA. 
/// Disable interrupts to avoid 
/// Possible reentrancy problems, 
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LAC (-ticks) /// Put the two's complement 

DAC* (SC.TMT) /// of ticks until next inter- 

/// rupt in SC.TMT. 

LAC savlnk /// Restore Link . . . 

RAL /// 

LAC saveac /// . . . and AC. 

ION /// Enable interrupts . . . 

.ENB /// 

JMP* timint /// ... after return. 

The user is responsible for saving and restoring the AC and Link plus 
all other registers and states. See Section 2.2.2 for a more detailed 
discussion. 

Interrupts must be disabled when the next .TIMER interrupt routine is 
scheduled to avoid possible re-entrancy problems. In the most general 
case, a . INH and lOF in combination are required to disable interrupts 
and an ION and .ENB in combination to enable interrupts. The lOF/ION 
pair is only required on machines which do not have API hardware 
installed ; whether or not API will be used does not matter. Similarly, 
the .INH/. ENB pair is only needed if API will be used. If the routine 
will always be run without API they may be deleted. 

Usually the same .TIMER interrupt routine will be used for the next 
interrupt. SC.TMA need not be updated if this is the case. SC.TMT 
must always be updated because it has been cleared to deactivate .TIMER. 

2.2.4 Using .TIMER Without API 

When .TIMER is used with a system which is also using API, there are 
essentially no restrictions on its use. There are certain guidelines 
which the programmer should follow, such as preserving registers and 
the like, but the programmer is free to disobey these guidelines if he 
so chooses. Doing so will almost always result in a malfunctioning user 
program, but should not affect system integrity. The reason for this 
is as follows. 

When API is in use, the XVM/DOS monitor can detect, at any instant in 
time, whether or not either a CAL routine or an interrupt routine is 
active. When the .TIMER time interval expires and the .TIMER interrupt 
occurs, the monitor checks to see if either a CAL routine or an interrupt 
routine is active. If so, the actual occurrence of the .TIMER interrupt 



_ 

The re-entrancy ECO package (ECO #KP15-49 through KP15-52) must also 
be installed. XVM/DOS cannot use API unless this ECO package is 
present. 
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is delayed until all such routines terminate and the monitor is quie~ 
scent. The net effect of this is that the interrupted program is 
always the user program. Whatever actions the .TIMER interrupt routine 
performs cannot disturb the integrity of the various monitor routines. 

All this no longer applies when API is not in use. The monitor is 
unable to determine whether or not a CAL routine or an interrupt routine 
is active. Therefore, when the .TIMER time interval expires, the inter- 
rupt occurs immediately. It is possible that some portion of the moni- 
tor will be interrupted, which implies that the .TIMER interrupt routine 
must follow certain programming conventions to preserve system integrity, 
System integrity may be violated if these conventions are not followed, 
possibly causing disk file structure corruption and other iindesirable 
results. 

The conventions necessary to preserve system integrity are described 
below. All of these are conventions which must be followed by .TIMER 
interrupt routines. 

1. The .TIMER interrupt routine must return to the interrupted 
code. 

2. All registers must be preserved. This specifically includes 
the AC, Link, MQ, SC, XR, LR, and auto- increment registers. 

3. The routine must not issue any CAL's nor modify any buffers 
or other locations being used by I/O handlers. 

These conventions ensure that the monitor routines will be able to 
complete successfully. 

While the user is expected to follow these conventions whenever pos- 
sible, there are some occasions where this cannot be done. The most 
common of these will be .TIMER interrupt routines which do not return 
to the interrupted code. On such occasions the user is advised to 
terminate I/O using the procedures outlined in Section 2.4. However, 
we must stress that successful operation cannot be guaranteed and must 
depend upon luck and the user's own knowledge. Any problems which 
occur will be timing dependent, and thus probably inconsistent and 
non-reproducible. 
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There is one other oddity which occurs when .TIMER is used without API. 
When API is in use, the return address stored at the .TIMER interrupt 
routine's entry point is an address within the user program. Thus, this 
address may be used to gather statistics about how much time is spent in 
various portions of the program. When API is not in use, on the other 
hand, this does not apply. Without API the return address is actually 
a constant, and thus useless for this purpose. 

2.2.5 Deactivating .TIMER Interrupts 

A pending .TIMER interrupt request may be deactivated by issuing the 
following CAL: 

.TIMER 0,0 

Within an interrupt routine the same effect should be achieved with: 

SC.TMT=16^ 

DZM* (SC.TMT) 

2.3 CONTROL CHARACTER ROUTINES 

XVM/DOS provides several control characters which interrupt the cur- 
rent program and transfer control to a specified routine. These con- 
trol characters are +C, +P, +S, +T, and tQ. All of these have stand- 
ardized meanings, described in the XVM/DOS User's Manual. The XVM/DOS 
monitor provides a default routine for each of the control characters 
(except +P) so as to implement the standardized meaning. A default 
routine cannot be supplied for +P, since its standardized meaning is 
to restart the current program from the beginning. The +P control 
character routine must be specified by the current program, as only the 
program knows how to re-initialize itself. 

Although default routines are supplied, the programmer is provided the 
capability to change them. The only exception is fQ, which is dedicated 



"+R is recognized and treated specially by the lOPS error processor. 
However, it does not perform the same function as the control charac- 
ters described here, i.e., interrupting the program and transferring 
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to its task. The remaining four control character routines (tC, +P, 
+S, and tT) may be respecif ied; however, the standardized meanings 
should be adhered to whenever possible so as to retain a reasonably 
simple and consistent human interface. 

There are two methods of specifying control routines, summarized in 
Table 2-1. The fS routine is straightforward, as the routine address 
is in .SCOM location SC.UST. The other three control character routines 
are specified by issuing a . INIT to TTA. , the console terminal I/O 
handler. The third argument of the .INIT is the routine address, with 
the high two bits of the word indicating which control character routine 
is to be changed. The .INIT may be issued to any .DAT slot assigned to 
TTA., although the examples use .DAT slot -3. For all four control 
characters, a routine address of zero causes that control character to 
be ignored. 

VJhen API is in use, no special precautions need be observed in writing 
control character routines. There are certain hazards present, however, 
when API is not in use. The essential problem is the possibility that 
the control character interrupt will occur when an I/O handler or 
some other portion of the monitor is executing. Interrupting the moni- 
tor at the wrong place can violate system integrity and cause file 
structure corruption. The monitor can avoid this problem when it is 
allowed to use API. See Section 2.2.4 for a detailed discussion of the 
analogous problem with .TIMER. 

This problem can be alleviated somewhat by having the control char- 
acter routine return to the interrupted code. This causes several 
additional problems, however, which are described below. A .SCOM 
location, SC.TTP, is provided to allow a control character routine to 
return to the interrupted code. Its use is typified by the following 
example control character routine: 

SC.TTP=116 

routine DAC saveac / Save AC 

LAC* (SC.TTP) / and return address 

DAC savepc 

RAR / and Link 

DAC savlnk 

/ Set a flag to indicate 

/ that the control character 

/ has been typed. 

LAC savlnk / Restore Link 

RAL 

LAC saveac / and AC 

JMP* savepc / then return. 
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The control character routine should follow the guidelines for .TIMER 
routines outlined in Section 2.2.4. 

Although having the control character routine return to the interrupted 
code does solve the system integrity violation and consequent file 
structure corruption problems, it also introduces two new problems. 
The first of these is a re-entrancy problem. If a second control chara- 
cter is typed too quickly following a first, the contents of SC.TTP 
will be lost and an indefinite loop may result. This problem is inherent- 
ly insoluble. The second problem results from lOPS errors. If the con- 
trol character was struck in response to an lOPS error, the very concept 
of returning from the control character routine is meaningless. The 
lOPS error processor checks for this and issues an IOPS35 error if a 
control character routine returns to it. 

The only real solution to the entire issue is to always use API. When 
using API, control character routines should never return. They may be 
coded to return anyway, but doing so will introduce the two problems 
described above. 

Table 2-1 
Specifying Control Character Routines 



Control 
Character 


Code j 
(Octal) ^ Method 


f S 


n/a 


■ 

SC.UST=lj2f6 

LAC (routine) 
DAC* (SC.UST) 


tc 

f P 
fT 


200000 


A00000 


.INIT -3 ,d,code+routine 


^^Q 


n/a 


None 



2.4 ABORTING I/O 

There are certain occasions in which the programmer may wish to abort 
I/O transfers which he has requested previously. This is particularly 
likely following a .TIMER or control character interrupt. The means 
of doing this is described below. 

The primary means of aborting I/O in progress is to issue a .INIT to 
the busy .DAT slot. This will abort most XVM/DOS I/O handlers. 
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One exception to this is the console terminal device handler, TTA. The 
following code sequence is necessary to abort console terminal I/O: 

SC.CTT=135 

XCT* (SC.CTT) 

This sequence must be executed before any further CAL's (including .INIT) 
are issued to TTA. 

2.5 THE lOPS ERROR PROCESSOR 

XVM/DOS provides two processors for lOPS errors. .MED is used to print 
a message including the lOPS error code followed by zero, one, or two 
octal values. The number of octal values is determined by the error 
code. The expanded error processor prints the same lOPS error message 
as does .MED, then follows it with an arbitrary string of text. Most 
XVM/DOS I/O handlers use the expanded error processor; the remainder 
use .MED. 

The lOPS error processors are intended for use by I/O handlers. The 
error processors, therefore, should only be called from CAL routines 
and interrupt routines ; they should not be called from mainstream. 

The expanded error processor obtains information for the error message 
from the five sources listed below. The .MED error processor obtains 
its information from the first three of these sources. The sources are: 

1. The AC contains the lOPS error code in the low 13 bits. 
The high 5 bits are ignored; thus the LAW instruction may 
be used. The expanded error processor, however, expects 
the AC to noinnally be negative and attaches a special 
meaning to a positive AC (see Section 2.5.2). Valid 
error codes are through 777 (octal) inclusive. 

2. For all errors except I0PS4, location .MED contains a 
value which is printed, in octal, following the lOPS 
error code. The CAL handler dispatch routine initializes 
.MED to the address of the CAL instruction. Thus, lOPS 
errors which print the CAL instruction address need not 
modify .MED. Note that this only works for CAL routines, 
not interrupt routines. 



■^This does not include .TIMER interrupt routines and control character 
routines. 
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3. If the error is an IOPS20 or I0PS21, the contents of 
SC.BBN is printed, in octal, following the contents of 
.MED. 

4. A string of .SIXBT text follows calls to the expanded 
error processor. This text is printed to terminate the 
error message. 

5. The Link specifies how nulls (character code 00) within 
the .SIXBT text are to be treated. If the Link is set, 
nulls will be printed as spaces. If the Link is clear, 
nulls will be ignored. 

The expanded error processor may also be called in such a manner that 
only the .SIXBT text will be printed; the first three items listed above 
will be ignored. Detailed specifications of the various calling 
sequences are given in the sections which follow. 

Errors may be either recoverable or non-recoverable. If the error is 
recoverable, and the operator types a fR, the error processor returns 
to the handler which called it. All registers except the AC and Link 
will be preserved. If the error is non-recoverable and the operator 
types a +R, the lOPS error message will be repeated. If the operator 
types any other control character (fP, fT, +C, fQ, or fS) the operation 
will be aborted and the error processor will not return to the I/O 
handler. Therefore, the programmer must ensure that the I/O handler 
and its tables are in a consistent state before calling an error pro- 
cessor. 

2.5.1 .MED 

When using the .MED error processor, only the I0PS4 error is recoverable, 
The following code sequence invokes an I0PS4 error message: 



.MED=3 



LAW 4 

JMS* (.MED) 



This causes the following message to be printed 



I0PS4 
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If the operator responds with a +R, the error processor will return 
following the JMS. The AC and Link will be changed; all other registers 
will be preserved. In all other cases, the error processor will not 
return. 

All other errors are non-recoverable, and are invoked by the following 
sequence : 

.MED=3 

LAC (miranminm) 
DAC* (.MED) 
LAW nnn 
JMP* (.MED+1) 

which causes the following message to be printed: 

lOPSnnn minitimmm 

where "nnn" is the lOPS error code number. The meaning of "mmmmmm" 
varies with different error codes. The error processor will never 
return. 

The only exceptions to this last calling sequence are the IOPS20' and 
I0PS21 errors. For these errors the sequence is modified to the 
following: 

.MED=3 
SC.BBN=132 

LAC (bbbbbb) 
DAC* (SC.BBN) 
LAC (mmmmmm) 
DAC* (.MED) 
LAW nnn 
JMP* (.MED+1) 

which causes the following message to be printed: 

lOPSnnn mmmmmm bbbbbb 

where "nnn" is either 20 or 21. By convention "bbbbbb" is the parti- 
cular disk or DECtape block number in which the error occurred. Other- 
wise this is identical to the previous variation. 
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2.5.2 The Expanded Error Processor 

The expanded error processor is invoked by a code sequence of the 
following form: 

.MED=3 

SC.BBN=132 

SC.EEP=137 

LAC (mmmmmm) 
DAC* (.MED) 
LAC (bbbbbb) 
DAC* (SC.BBN) 
CLL or STL 
LAW nnn 
JMS* (SC.EEP) 
JMP recover 
-count 
.SIXBT "text" 

This causes one of the following four forms of messages to be printed: 

I0PS4 text 

lOPSnnn mmmmmm text 

lOPSnnn mmmmmm bbbbbb text 

text 

The expanded error processor selects one of the first three forms 
based upon the lOPS error code number "nnn" . An error code of 4 results 
in the first form listed. The codes 20 and 21 result in the third 
form. All other codes result in the second form. The fourth form, 
in which the lOPS portion of the message has been suppressed, is 
selected via a mechanism described below. 

As with the .MED error processor, the meaning of "mmmmmm" varies with 
the error code number. By convention, "bbbbbb" is the particular disk 
or DECtape block number in which the error occurred. If the form being 
used does not include either or these values, the location containing 
it (.MED for "mmmmmm" or SC.BBN for "bbbbbb") need not be set up, 
allowing a portion of the code sequence above to be omitted. 

The first three message forms above (the lOPS forms) all require that 
the AC be negative when the error processor is called. This will happen 
quite naturally if the LAW instruction is used. If, however, the AC is 
positive, the fourth message form results. The lOPS portion is omitted 
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zero; AC values greater than zero are undefined. Locations .MED and 
SC.BBN need not be set up. 

In the code sequence above "text" stands for an arbitrary .SIXBT text 
string. This text string is printed following the lOPS portion of the 
message (if present) . Null characters within the text string will 
either be ignored or converted to spaces, depending upon the value of 
the Link. If the Link is clear, nulls will be ignored; if it is set, 
they will be converted to spaces. A null is the character code 00. 
Nulls may be inserted in a .SIXBT text string by specifying the "@" 
character. This feature allows an I/O handler to easily format an 
error message, by concatenating various segments aligned on word 
boundaries. 

The length, in words, of the .SIXBT text string is represented by "count" 
in the code sequence above. The two's complement of the length should 
be provided. If the value provided is positive or zero, the text string 
will be omitted. 

The expanded error processor considers all errors to be potentially 
recoverable. The error processor returns following the JMS if the 
operator types a fR. If the error is in fact recoverable, this location 
should be a JMP to a recovery routine. If the error is non-recoverable, 
this should be a JMP, which loops back to re-call the error processor. 
Note that the AC and Link have been modified and must be restored before 
the error processor is re-called. 

2.6 . MTPAN 

XVM/DOS provides an interface to the system bootstrap, implementing 
transfers to and from the system disk. This interface is via the .MTRAN 
(Monitor TRAN) CAL function. .MTPAN is a system macro; its expansion 
is given in Appendix E. 

.MTRAN should be invoked with a code sequence similar to the following: 

LAC (prmblk) 
CLL or STL 

. MTRAN 

The .MTRAN CAL does not return in the normal fashion; when the transfer 
completes the program continues in a manner described below. The state 
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of the Link indicates the transfer direction. If the Link is clear, 
information is read from the system disk into core. If the Link is 
set, information is written from core onto the system disk. The loca- 
tion and length of the transfer is determined by a four word parameter 
block. The address of the first word of the parameter block is conveyed 
in the AC. The parameter block takes the following form: 

prmblk blknum / first disk block. 

coradr-1 / starting core address 

-length / two's complement transfer length 

restart / program restart address 

The first word contains the number of the first disk block to be trans- 
ferred. The second word contains one less than the core address at 
which the transfer is to start. The third word contains the two's com- 
plement of the number of words to transfer. The fourth word contains 
the address at which the program should continue when the transfer is 
complete. .MTRAN does not return in the normal fashion, to the location 
following the CAL expansion. Rather, it returns to the address specified 
in the fourth word of the parameter block. Upon return from a .MTRAN, 
all registers have been altered. All that is preserved is the current 
addressing mode - both bank vs. page mode and XVM mode enable/disable. 
Note that the parameter block must reside entirely within the first 32K 
words of core . 

Although XVM/DOS provides this interface to the system bootstrap, its 
use is discouraged. Using the bootstrap requires that the entire 
interrupt system be shut down. The programmer is encouraged to use the 
.TRAN function of a conventional disk handler whenever possible. 

If a disk error is encountered while performing a .MTRAN, the following 
message will result: 

I0PS4 

This message results for all errors, not just drive-not-ready errors. 
Typing a fR will cause the transfer attempt to be repeated. 

2 . 7 XVM MODE 

Unlike bank and page modes, the programmer may dynamically turn XVM 
mode (17-bit addressing mode) on and off within his program."^ This is 



Only the system loader may switch between bank and page modes, as the 
XVM/DOS monitor and associated I/O handlers must be reconfigured. 
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accomplished with the .XVMON and .XVMOFF CAL functions. These functions 
are provided as system macros . 

In order to use these CAL's, the programmer must ensure that XVM mode 
has been enabled. This is accomplished by issuing the XVM ON command 
to the non-resident monitor. If XVM mode is disabled (XVM OFF) , the 
.XVMON CAL will result in an I0PSJ3t error. The .XVMOFF CAL will still 
execute successfully, however. 

It should not be necessary for the user to issue either of these CAL's 
when the system is used normally. All DEC supplied system programs 
run with XVM mode turned off. Accordingly, the system loader always 
leaves XVM mode off. The Linking Loader and Execute, both of which 
load user programs, turn on XVM mode (issue a .XVMON) if XVM mode has 
been enabled. 

2 . 8 ADVANCED . GET/ . PUT 

There are a number of options included in the .GET and .PUT CAL functions 
which are not described in the XVM/DOS Users Manual. These options are 
controlled by various flags in the first argument (the function argument) 
to the .PUT and .GET system macros. 

Every function performed by .PUT or .GET results from three operations 
performed in sequence. These operations may be selectively omitted or 
altered by various flags within the function code and by whether the CAL 
is a .PUT or a .GET. The meanings and octal values of the flags are 
summarized in Table 2-2. 

The three operations comprising .PUT and .GET are as follows: 

1. Core dump. The monitor first closes all open files. Then, 
if the CAL is a .PUT, it transfers the core image into 

the fQ area on the system disk. 

2. File transfer. The fQ area is transferred to or from 
the named disk file, or else no operation takes place. 
If the flag SC.QNF is set in the function code, this 
operation is skipped and no file transfer operation takes 
place. If the flag is clear, the transfer operation will 
be performed in a direction determined by the flag SC.QPUT. 
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3. 



If SC.QPUT is clear, the file named by the .GET CAL is 
copied into the +Q area. If SC.QPUT is set, the tQ 
area is copied to the file. Note, however, that the flag 
SC.QPUT is complemented when the CAL is a .PUT. Thus, 
the meanings of this flag become reversed from what is 
described above. 

Exit. ir the flag SC.QNRM is set, the system exits to 
the non-resident monitor. If SC.QNRM is clear, the fQ 
area is brought into core and control is returned to 
the user program. The manner in which controx is re- 
turned is determined by the return code portion of the 
function code, described in the XVM/DOS Users Manual. 



In the course of these operations numerous error checks are performed. 

Table 2-2 
.GET/. PUT Special Function Flags 



Flag 


Octal Value 


Meaning 


SC.QNF 


2000 


Skip file transfer operation 


SC.QPUT 


A00 


Determine direction of file 

transfer. Meaning when .GET: 

set => tQ area^- file 
clear => File^ tQ area 

These meanings are reversed 

when used with .PUT. 


SC.QNRM 


1000 


Exit to non-resident 

monitor when finished, rather 

than restoring core image 



The core image saved and restored by .PUT and .GET does not include all 
of core. Locations ^ to 4 are never included. This should be of no 
consequence to the user, as these locations are reserved for the monitor, 
It is also possible that the image will not extend to the top of memory. 
If the +Q area is shorter than the current system memory size, the 
image will be truncated to the +Q area length. Note that memory above 
the bootstrap may be omitted from the saved (and subsequently restored) 
image without a warning message ever appearing. 
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Example 1 : 

The non-resident monitor command line: 

$ PUTtjF I LNAMt_jEXT 
might be translated to the following code sequence: 
.GET SC.QNRMlSC.QPUT,filblk 



filblk .SIXBT "FILNAM" 
.SIXBT "EXT" 

Example 2 : 

The action performed by a +Q is closely approximated by the following 
code sequence : 

SC.QNRM=l(ar00 
SC.QNF=2J2f^0 

.PUT SC.QNRM!SC.QNF,0 
The monitor actually uses this code sequence to implement +Q, after 
first modifying the .GET CAL function routine. See Chapter 3 for 
more details. 

2.9 TASK CONTROL BLOCKS 

Communication between the XVM processor and the UNICHANNEL (PDP-11) 
processor is performed through blocks of information called Task 
Control Blocks. These blocks are resident in the first 4K words of 
XVM memory where they can be accessed by both processors. The TCB 
(Task Control Block) contains all the information necessary for the 
processing of a UNICHANNEL request. For more details refer to the 
XVM UNICHANNEL Software Manual. 

Space for Task Control Blocks is allocated whenever the UC15 option 
is enabled. This option is enabled with the UC15 ON command and 
disabled with the UC15 OFF command. The UC15 OFF command will re- 
claim (for other purposes) the space allocated to the Task Control 
Blocks. 

Task Control Blocks are accessed by means of .SCOM location SC.TCB. 
If the UNICHANNEL is disabled (UC15 OFF) , the TCB area is not 
allocated and SC.TCB contains zero. Otherwise, SC.TCB points to 
a table of transfer vectors, containing one location for each TCB. 
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Each location in this table is fixed, corresponding to a particular 
TCB. This table is currently nine words long, as there are currently 
nine TCB's. Existing table locations will not be changed in the 
future; changes will be implemented by adding additional table loca- 
tions. 

Each potential Task Control Block has a dedicated location in this 
transfer vector table. This location will be zero if the associated 
TCB has not be allocated. Otherwise, it will be the base address 
of the TCB. The length of the TCB is determined when the resident mon- 
itor is assembled. Each TCB has a standard default length. While users 
may change the length, they should do so with caution, as all software 
which may reference that TCB must be modified to reflect the change. 

The various Task Control Blocks, the assembly parameters which con- 
trol their generation, and their transfer vector locations within the 
table pointed to by SC.TCB are all summarized in Table 2-3. Which 
TCB's are allocated, and the length of each TCB when it is allocated, 
is determined by several assembly parameters to the resident monitor. 
Each TCB has its corresponding assembly parameter. If the parameter 
is left undefined, the TCB will not be allocated. If the parameter 
is defined equal to zero, the default length will be used. If the 
parameter is defined with a non-zero value, that value is used for 
the TCB's length and the default length overridden. 

There are two exceptions to the above rule. Both the disk Task Con- 
trol Block (RKTCB) and the line printer Task Control Block (LPTCB) 
will always be generated. This occurs even if the assembly parameters 
are left undefined, as these two TCB's are required by various pieces 
of system software. 

We wish to stress that the foregoing discussion of TCB assembly para- 
meters only applies when the UNICHANNEL is enabled. When the UNI- 
CHANNEL is disabled (UC15 OFF), no TCB's are allocated, regardless of 
what assembly parameters are used. The assembly parameters determine 
which TCB's will be allocated when the UNICHANNEL is enabled (UC15 ON). 
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Table 2-3 
Task Control Blocks 



Offset-^ 


Assembly ^ 
Parameter 


Default^ 
Length ^ 


Use 


^ 


RKTCB* 


21 


Cartridge disk TCB 


1 


LPTCB* 


117 


Line Printer TCB and Buffer 
area 


2 


CDTCB 


65 


Card Reader TCB and Buffer 
area 


3 


PLTCB 


117 


XY (incremental) Plotter TCB 
and Buffer area. 


4 


TCBl 


24 


Spare TCB and Buffer area #1. 


5 


TCB2 


120 


Spare TCB and Buffer area #2. 


6 


TCB 3 


170 


Spare TCB and Buffer area #3. 


7 


LVTCB 


120 


Printer/Plotter (electro- 
static) TCB and Buffer area. 


10 


DLTCB 


54 


Communications TCB and Buffer 
area. 


The offset, shown in octal, detenni] 


les the location of the TCB's 


transfer vector within the table pointed to by SC.TCB. The fol- 


lowing code sequence loads the AC with the base address of a TCB: 


SC.TCB=2J2r^ 




LAC* (SC.TCB) 

SNA 

JMP tcb not allocated 

AAC offset 

DAC temp 

LAC* temp 

SNA 

JMP tcb not allocated 




2 

The two TCB's flagged with an aster; 


Lsk are always^ generated. 


Leaving either RKTCB or LPTCB undef: 


Lned is equivalent to setting 


it equal to zero. 




The default lengths are expressed ii 


1 octal. 
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2.10 MINI-ODT 



NOTE 

Mini-ODT is an UNSUPPORTED feature of 
XVM/DOS. It is described here as a con- 
venience to customers who may wish to 
use it in spite of this restriction. 

Mini-ODT is an optional feature of the XVM/DOS resident monitor. It 
is included in the monitor by defining the following assembly para- 
meter when assembling RESMON: 

%ODT=0 

If present, Mini-ODT will be invoked on all lOPS errors. The +T 
control character routine will, by default, be Mini-ODT. Thus, typing 
a +T will invoke Mini-ODT unless the user program respecifies the +T 
control character routine or DDT, Batch or BOSS is in use. All in- 
teraction with Mini-ODT occurs via the console terminal. 

When an lOPS error occurs, Mini-ODT prompts for a command on the line 
following the normal lOPS error message. When Mini-ODT is invoked 
via +T, it types a line of information and prompts for a command on 
the following line. The line of information is of the form: 

ODT > PC=pppppp AC=aaaaaa 

This line describes the contents of the PC and AC when the +T inter- 
rupt occurs. 

Mini-ODT prompts for commands by printing the following sequence at 
the left margin: 

ODT > 

Note that every line printed by Mini-ODT begins with this same se- 
quence. Legitimate commands are listed in Table 2-4. If an invalid 
command is entered, Mini-ODT types two question marks, closes any 
open location, and prompts for a new command. 
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Table 2-4 
Mini-ODT Commands 



Command 


Action 


nnnnnn/ 


Close any open location, then open location 




nnnnnn and print its contents. Always legal. 


J 


Close the currently open location , then open 


the next location in sequence and print its 




contents. Illegal if no location is open. 


nnnnnn ^ 


Store nnnnnn in the currently open location 




and close it, then open the next location in 




sequence and print its contents. Illegal if 




no location is open. 


$ 


Close any open location. Always legal. 


nnnnnn$ 


Store nnnnnn in the currently open location 




and close it. Illegal if no location is 




open. 


fP, +C, tT, 


Same meaning as with error processor without 


+ S, fQ 


Mini-ODT. Exits error processor and Mini- 




ODT and transfers to control character rou- 




tine . 


R 


Return from error processor and Mini-ODT. If 




Mini-ODT was invoked by an lOPS error, the 




handler retrys the I/O transfer. If invoked 




by fT, resume the interrupted program. 


Key: 




nnnnnn 


Any octal number 


J 


Carriage return 


$ 


Alt Mode. A dollar sign will not be 




echoed. 
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2.11 RESIDENT MONITOR PATCHING FACILITIES 

There are two distinct types of patching available with the XVM/DOS 
resident monitor. The first of these provides what is normally meant 
by a patch area. This method is appropriate for altering the resident 
monitor. The second method, although using what is termed the resi- 
dent patch area, is really a means of communication between different 
core loads. 

To add code (presumably a patch) to the resident monitor, the following 
procedure should be followed. Using the Patch XVM utility program, 
examine location 101 within the disk image of RESMON. This location's 
contents is the address of the first free location above the resident 
monitor. The code and data should be inserted beginning at this address, 
and the contents of location 101 updated to reflect the monitor's in- 
creased length. 

The second patching method uses the aforementioned resident patch area. 
The resident patch area is allocated by SGEN XVM when a non-zero re- 
sponse is given to the question: 

RESIDENT PATCH AREA SIZE [0] 

The response to this question determines the length (in words) of the 
resident patch area. The base address of the resident patch area is 
contained in location 101 of the disk image of RESMON. Note that 
patching the resident monitor via method 1 above will relocate the 
resident patch area. 

The resident patch area gets its name from the fact that it is truly 
resident. It is initialized from the monitor's disk image upon a 
manual bootstrap load (cold-start) . Following this it is left un- 

which is constantly refreshed. Thus it is a convenient method of 
communication between core loads. 

It should be noted that references to location 101 apply only to the 
disk image of RESMON. This location is- changed when the monitor is 
brought into core and initialized. The programmer must also be aware 
that an upper limit is placed on the- combined sizes of the two patch 
areas when the resident monitor is assembled. The patch areas should 
be restricted to a total combined length of no more than 1000 (octal) 
words. 
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2.12 API SOFTWARE INTERRUPTS 

This section presents the coding conventions which should be followed 
when a particular API software interrupt level is shared among several 
uses. The conventions must be followed by the user if he uses level 4, 
as the XVM/DOS monitor and I/O handlers use level 4 also. They need 
not be followed with levels 5, 6, and 7 as these levels are reserved 
exclusively for the user. However, it is still recommended that these 
conventions be followed, to allow the levels to be used for additional 
purposes. 

The routine which requests a level 4 software interrupt should be 
coded as follows: 



API.R4=404J2r0j2f 
SC.LV4=112 
.INH=705522 
.ENB=705521 



.INH 


/// 


RPL 


/// 


AND (API.R4) 


/// 


DAC svrqst 


/// 


LAC* (SC.LV4) 


/// 


DAC svvctr 


/// 


LAC (API.R4) 


/// 


ISA 


/// 


LAC (routine) 


/// 


.ENB 


/// 


DAC* (SC.LV4) 


/// 



Save previous level 
4 request. 

And the interrupt 
vector. 

Issue a request 
for our routine. 



This coding sequence saves a current software interrupt request (if 
one is present) so that it may be restored later. Interrupts are dis- 
abled so that an interrupt routine, itself trying to schedule a soft- 
ware interrupt, won't find things in an inconsistent state. An anal- 
ogous coding sequence should be followed with software levels 5, 6, 
and 7, substituting the appropriate mnemonics and values from Table 2-5 
for API.R4 and SC.LV4. 

The software interrupt routine must be coded to complement the re- 
questing routine above. The interrupt routine should be coded as 
follows: 
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SC.LV4=112 

.INH=7j2f5522 

.ENB=705521 

routine 

.INH 



DAC saveac 

LAC svrqst 

ISA 

LAC svvctr 

.ENB 

DAC* (SC.LV4) 



/// Software interrupt 
/// routine entry point, 
/// save AC. 
/// Restore previous 
/// level 4 request. 
/// And its interrupt 
/// vector. 
/// 



LAC saveac 

DBR 

JMP* routine 



/ Restore the AC 

/ and operating modes 

/ and return. 



This routine restores the previous software interrupt request which 
was saved by the scheduling routine. It is essential that no inter- 
rupts be allowed after the moment the software interrupt is granted 
until the previous request has been completely restored. Routines 
for levels 5, 6, and 7 should be coded in a like manner, substituting 
the appropriate mnemonic and value from Table 2-5 for SC.LV4. 

The programmer should note that XVM mode is turned off when the soft- 
ware interrupt occurs. A . XVMON CAL should be issued if XVM mode is 
required within the software interrupt routine. The DBR instruction 
used to return from the software interrupt routine causes XVM mode to 
be restored to the proper state. 

The programmer must also remember that software interrupts may only be 
used when XVM/DOS has been conditioned to use API. This conditioning 
occurs when the API ON command is given. Enabling the API hardware 
when the Tnonitor is not so conditioned (API OFF) is erroneous. 
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Table 2-5 
API Software Interrupt Vectors and Request Flags 



Priority 
Level 


Interrupt Transfer Vector 


Request Flag 


Mnemonic 


Octal Value 


Mnemonic 


Octal Value 


4 
5 
6 
7 


SC.LV4 
SC.LV5 
SC.LV6 
SC.LV7 


112 
113 
114 
115 


API.R4 
API.R5 
API.R6 
API.R7 


404000 
402000 
401000 
400400 



2-27 



CHAPTER 3 
THE RESIDENT MONITOR 

This chapter contains information concerning the internal operation of 
the resident monitor for those who may wish to alter it. These altera- 
tions, however, are not supported by Digital Equipment. 

A fresh copy of the resident monitor is built for each core load and 
becomes a permanent part of the core load. The .SCOM table, which 
contains absolute locations used to communicate between XVM/DOS com- 
ponents, is an important part of the resident monitor. The resident 
monitor also contains the CAL handler and associated CAL function rou- 
tines, the console terminal I/O handler (TTA. ) , plus various pieces of 
optional, specialized code for BOSS, Batch, VT ON, and other features. 

3.1 RESIDENT MONITOR INITIALIZATION 

A fresh copy of the resident monitor is built for every core load by 
reading it from disk into core and transferring to the initiali- 
zation code. Usually this process is used by the monitor to rebuild 
itself for a new core load. A less common use of this process is for 
a manual bootstrap or cold start. 

Manual bootstrap loads read the resident monitor into bank zero of core. 
The initialization code copies the monitor to the memory bank in which 
the bootstrap resides and transfers control to that bank. Next .SCOM 
is cleared and selected locations initialized. The contents of SGNBLK 
are the primary information sources for initializing .SCOM. 

These steps construct an approximation to an operational core image, 
allowing the completion of the initialization process using the more 
common monitor rebuild procedure. This procedure is described below. 

Whenever a new core load is constructed, the resident monitor is read 
into the memory bank in which the bootstrap resides. The monitor 
initialization code is executed, rebuilding the monitor in bank zero. 
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Upon completion of this build procedure the initialization code overlays 
itself with the system loader (.SYSLD). The system loader completes 
the core load by loading the appropriate system program and requested 
I/O handlers. The rest of this section describes the initialization 
code in more detail. 

Immediately upon being entered the initialization code (executing in 
the bootstrap's bank) saves certain key tables from the previous core 
load's monitor. At this time the previous core load's monitor is 
still in bank zero. The tables which are saved include the old .SCOM, 
the .DAT and .UFD tables, and the VT ON display buffer (if present). 
After these tables are saved, low memory — in particular .SCOM — is 
zeroed. 

At this point the build procedure begins. The new .SCOM is built using 
the old .SCOM and SGNBLK as primary data sources. Entries in .SCOM 
are checked for validity in terms of the current hardware configuration, 
and altered if necessary. The monitor is copied into bank zero and 
configured for the current operating modes. Other system tables are 
set up and initialized. These tables include the skip chain and the 
.DAT, .UFD, and TCB tables. Finally the interrupt system is turned 
on and the system loader brought into core. 

Monitor appendages play an important role in configuring the resident 
monitor for various operating modes. A monitor appendage is a section 
of code which may easily be included as part of the monitor or left out 
and the space recovered for other purposes. Monitor appendages are used 
to implement many optional features, such as Batch and BOSS modes and 
VT ON. 

A monitor appendage is divided into two sections. The first section 
is instructions, the second absolute constants. The monitor initiali- 
zation code checks if the appropriate option is enabled, and calls a 
routine (IN. MOV) to add the appendage if appropriate. This routine 
relocates all memory reference instructions and copies the rest of the 
appendage, including the absolute constant section, without modification, 
The necessary registers are modified to reflect the increased size of 
the monitor. Note that no provision is made for relocatable constants -- 
any such must be handled separately. 
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3.2 THE CAL HANDLER 

The CAL handler is a basic dispatch routine. There are two varieties 
of CAL's, each handled separately. If the CAL is an I/O CAL, the .DAT 
slot number is determined from the CAL instruction and the I/O handler 
address obtained from the .DAT table. The CAL handler transfers to 
the I/O handler via a JMP instruction, with the CAL instruction address 
in the AC. 

Non-I/0 CAL's are performed by CAL function routines internal to the 
resident monitor. The CAL handler obtains parameters from the^CAL 
expansion and stores them in places convenient for the CAL function 
routines. The CAL handler then invokes the appropriate CAL function 
routine via a JMS instruction. When the CAL function routine returns, 
the CAL handler returns to the user program. A more detailed descrip- 
tion is provided by the accompanying flow diagrams (Figure 3-1) and by 
comments included in the resident monitor. 

The above description of the CAL handler is greatly simplified, as it 
completely ignores a major problem which may occur. This problem centers 
upon the possibility of certain interrupts occurring during monitor 
processing. The interrupts in question are control character interrupts 
from the console terminal keyboard and clock interrupts which cause a 
.TIMER routine to- be invoked. The troublesome characteristic of these 
interrupts is that they cause an asychronous transfer of control in 
the user program. If the problem were ignored, and an I/O handler or 
the monitor were interrupted, various internal tables could be left 
in an inconsistent state. Such a violation of system integrity can 
have consequences as far reaching as disk file structure corruption. 

The solution to this problem is to provide a way to determine whether 
or not the monitor is active — i.e. whether the monitor or the user 
program is interrupted. If the monitor is inactive, the control chara- 
cter or .TIMER interrupt takes effect immediately. If the monitor is 
active, the control character or .TIMER interrupt should be delayed 
until monitor activity terminates, so that only the user program is 
affected. This solution is in fact achieved when API can be used. 
Without API, however, the problem still exists. 

The API solution makes extensive use of level 4 software interrupts, 
and the fact that CAL instructions implicitly raise the processor to 
level 4. The CAL handler uses these techniques to maintain a CAL level 
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counter, indicating the nesting depth of currently active CAL's. Every 
time a CAL is issued, the CAL handler increments the CAL level counter 
and requests a level 4 software interrupt. When the CAL function routine 
completes, it returns, simultaneously dropping below API level 4. The 
level 4 software interrupt occurs, allowing the CAL level counter to 
be decremented. If the counter reaches zero, all CAL's have completed 
and the user (mainstream) program is active, so the handler drops back 
to mainstream and returns from the software interrupt. If the counter 
hasn't reached zero, a CAL function routine (which has just itself 
issued a CAL) is still active, so the handler remains at level 4 when 
it returns from the software interrupt. These operations are further 
described in Figure 3-1. 

The above procedure maintains an indication of whether or not a CAL 
routine is active. Note that this works equally well for both I/O CAL's 
processed by I/O handlers and non-I/0 CAL's processed internally. There 
must also be a way to detect if an interrupt routine is active. This 
is quite easily achieved, however, as all interrupt routines operate at 
API levels 4 and above. 

This information about CAL and interrupt routine activity is used by 
the monitor when processing control character and .TIMER interrupts. 
The logic to handle this is contained in a monitor subroutine, RQ.LV4. 
RQ.LV4 is called by an interrupt routine to schedule an auxiliary 
routine for execution at a later time. An auxiliary routine is identi- 
cal to a level 4 software interrupt routine, with two exceptions. The 
important difference is that the "software interrupt" which invokes the 
auxiliary routine is guaranteed to interrupt the user program, rather 
than any portion of the monitor. Thus when the auxiliary routine 
receives control, the monitor is inactive and all CAL and interrupt 
routines have completed. The second difference between an auxiliary 
routine and a level 4 software interrupt routine is that an auxiliary 
routine need not restore a previous software interrupt request (see 
Section 2.12) . 

When RQ.LV4 is called to schedule an auxiliary routine, it firsts checks 
the CAL level counter to see if a CAL function routine is active. If 
no CAL function routines are active, it requests a level 4 software 
interrupt and invokes the auxiliary routine when the software interrupt 
is granted. If a CAL function routine is active, however, it arranges 

for "HVlf* 1 ^^XT'Pil L c;(tF+-t«73 -TO i irHci-rT-iTn-l- ¥ r\ T-io r- ci mi o a -f- q r? T.rViia'n all =/^-i-TTTo PST. 
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CAL 



Enter CAL handle 



Initialize error 
processor (.MED) tc 
print CAL address. 




Request a level 4 
software interrupt 
for routine CL.LV4. 



L 



I 




KEY 



Normal transfer of 
"^ control 



Interrupts disabled 



Figure 3-1 
The CAL Handler 
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Restore the CAL 
vector (location 20) 
to trap indirect 
CAL'S (CAL*'s) . 



Save the CAL in- 
struction (word 1 of 
the CAL expansion). 



Fetch the CAL func- 
tion code (word 2 of 
the CAL expansion). 




Figure 3-1 (cont) 
The CAL Handler 
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Set up dispatch to 
CAL function routin 



Merge unit number 
from .DAT slot into 
word 2 of the CAL 
expansion. 



Update CAL return 
address for length 
of CAL expansion. 




Invoke CAL functi 
routine (via JMS) . 



Put CAL address (with 
operating mode bits) 
into AC. 



Restore AC. 
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CAL handler by 
( transferring to I/O 
V handler. 



Restore operating 
modes, drop to ma 
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1 



/ Enter I/O handler- 




KEY 



Control transfer v 
trap or interrupt 




Figure 3-1 (cont) 
The CAL Handler 
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Figure 3-1 (cent) 
The CAL Handler 
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KEY 



Interrupts disabled 



Figure 3-1 (cont) 
The CAL Handler 
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function routines terminate. This logic is illustrated by Figure 3-2. 
The interaction with the CAL level counter ensures that all CAL function 
routines have completed when the auxiliary routine is invoked; the level 
4 software interrupt request ensures that all interrupt routines are 
complete . 

The use of RQ.LV4 is well illustrated by the .TIMER interrupt logic. 
When the clock interrupt routine detects that the .TIMER time interval 
has expired, it calls RQ.LV4 to schedule an auxiliary routine. Follow- 
ing this, the clock interrupt routine continues operation and completes 
normally. Ultimately the auxiliary routine is invoked via the procedure 
described above. The auxiliary routine, in turn, actually invokes the 
user's .TIMER interrupt routine. 

The foregoing discussion has described a solution to the system integrity 
problem which centers upon control character and .TIMER interrupts. As 
stated previously, this solution uses API extensively — particulary 
level 4 software interrupts. Vlhen API cannot be used (either because 
it isn't present or because its use has been disabled), this solution is 
inapplicable; the problem becomes insoluble and it most frequently mani- 
fests itself as disk file structure corruption. 

An example of how this problem might occur is as follows. Suppose a 
user were to use the PIP XVM utility program to delete a disk file. 
Furthermore suppose that the filename was typed incorrectly, but that 
the error was not discovered until after the command line was terminated 
with a carriage return, so that the wrong file would be deleted. Upon 
discovering this error, most users would immediately try to abort the 
deletion with a +G or +P which would be too late to save the file. How- 
ever, unless the file were extremely short, this would cause disk cor- 
ruption = Specifically, some of the blocks which had been allocated to 
the file would be lost from the disk's bit maps and unavailable for 
further use. 

Even though this problem is inherently insoluble without API, we cannot 
just ignore it. We must exert some effort to preserve the correct 
status of XVM or user mode (see Section 3.4). A user program may execute 
in either user mode or exec mode, whereas the monitor always executes in 
exec mode. This requires attention in conjunction with .TIMER and 
other user interrupts which might return to the interrupted code. 



3-10 



RQ.LV4 
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Figure 3-2 
The Auxiliary Routine Scheduler, API Version 
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Figure 3-2 (cont) 
The Auxiliary Routine Scheduler, API Version 



3-12 



RQ.LV4 



ipts y U: 



Give interrupt return 
address to" auxiliary 
routine. 



Merge operating mode 
bits from interrupt 
return address with 
auxiliary routine 
entry point address. 
Force user/exec mode 
bit to exec mode. 
Store in the inter- 
rupt vector so this 
will replace the 
interrupt return 
address. 



Return from RQ,LV4. 



/interrupt routine 
( resxmes following 
Y JMS RQ.LV4. 



Interrupt routine 
executes to ccMnple- 



/interrupt routine 
/ returns, restoring 
I all operating modes 

\except user mode. 



Auxiliary routine 
executes to comple- 
tion. 



/Auxiliary routine 
/ returns to interrupt 
I routine, restoring 

\all operating modes. 



KEY 



Normal transfer of 
control 



Interrupts disabled 



Figure 3-3 
The Auxiliary Routine Scheduler, Non-API Version 
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Suppose the monitor is active when a .TIMER interrupt occurs. We must 
leave exec mode and enter user mode before calling the user's .TIMER 
interrupt routine. Correspondingly, when the .TIMER interrupt routine 
returns, we must restore exec mode before returning to the monitor. 
These mode transitions are handled by the auxiliary routine. The non- 
API version of the auxiliary routine enters user mode (if appropriate) 
and invokes the user's .TIMER interrupt routine via a JMS instruction. 
If the user's .TIMER interrupt routine returns from the JMS, the auxil- 
iary routine will return to the interrupted code with a DBR instruction, 
so that all operating modes will be restored correctly. 

This raises one final point. Although auxiliary routines and RQ.LV4 are 
primarily useful with API, they are also used without API as a coding 
convenience. Recall that RQ.LV4 may only be called from an interrupt 
routine. When API is not in use, RQ.LV4 will schedule the auxiliary 
routine for execution immediately following termination of the interrupt 
routine which called RQ.LV4. The non-API variation of RQ.LV4 is depicted 
by Figure 3-3. 

3.3 REAL TIME CLOCK OPERATION 

The XVM/DOS resident monitor uses the KW15 real time clock to maintain 
timing information and to schedule various routines. The clock inter- 
rupt routine, CK.INT, is depicted in Figure 3-4 as is the clock startup 
routine, CK.STRT. The clock startup routine is used to restart the 
clock following a CAF instruction. 

Several .SCOM locations are used in conjunction with the clock routines 
for timing purposes. These .SCOM locations are described in Table 3-1. 
Note that .SCOM locations should only be referenced by equating their 
mnemonic to their location, and then using the mnemonic as the actual 
address. Following this convention facilitates readability and future 
alteration to .SCOM. 
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Figure 3-4 
Real Time Clock Routines 
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Figure 3-4 (cont) 
Real Time Clock Routines 
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Figure 3-4 (cont) 
Real Time Clock Routines 
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Figure 3-4 (cont) 
Real Time Clock Routines 
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Table 3-1 
Clock Oriented .SCOM Locations 



Location 



Mnemonic 



Description 



134 



SC.ETS 



Elapsed time in seconds. Incremented 
once per second. Used in BOSS mode 
for job run time accounting. 



147 



SC . DAY 



Today's date, or zero if the date is 
unknown . Format : 






5 


6 


11 


12 


17. 


month 
— 1 — 1 I I I 


day 
1 1 1 1 1 


year 

1 I ! I J. 



where month is the calendar month (one 
corresponds to January) , day is the 
date within the month, and year is 
years since 1970 (one corresponds to 
1971) . 



150 



SC.TIM 



The current time of day, kept as 
a 24 hour clock. Format: 
.0 5j6 11,12 17, 



hours 



J ! I L 



minutes 



_1 ! ! ! L. 



seconds 



J I ' ' ' 



where hours, minutes, and seconds 
express the time since midnight. Mid- 
night is denoted by all fields contain- 
ing zero. Note that this location must 
be initialized via the TIME command for 
the time of day to be accurate. 
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SC.ETT 



Elapsed time in ticks. Incremented at 
the power line frequency. This location 
may be modified by the user, as it is 
not used by system programs. 



156 



SC.TLM 



160 



SC.TMT 



Two ' s complement of the number of seconds 
remaining in the current time limit, 
or zero if no time limit in effect. 
Time limits are requested with the 
TIMEST command or as part of BOSS ' s 
$JOB card. 



Two's complement of the number of clock 
ticks (at the power line frequency) 
remaining until the current .TIMER 
interrupt occurs, or zero if no .TIMER 
interrupt request is active. 
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Table 3-1 (cont.) 
Clock Oriented .SCOM Locations 



Location 


Mnemonic 


Description 


161 


SC.TMA 


The address of the .TIMER interrupt 
routine associated with the current 
.TIMER interrupt request. 


171 


SC.TDT 


Tomorrow's date, or zero if tomorrow' 
date is either unknown or not yet 
determined. Format: 

.0 5,6 11,12 17 


s 




month 
f , 1 1 1 


day 
I I 1 I 1 


year 
1 1 1 1 1 




where month is the calendar month 
(one corresponds to January) , day is 
the date within the month, and year 
is years since 1970 (one corresponds 
to 1971) . This location is cleared 
(i.e. tomorrow's date becomes undeter- 
mined) at midnight and is reinitialized 
the next time the non-resident monitor 
is loaded. 


173 


SC.TMR 


Two's complement of the number of clock 
ticks (at the power line frequency) 
left in this second. 


174 


SC.LFR 


Two's complement of the power line 
frequency — i.e. the number of clock 
ticks in each second. 



3.4 THE UNICHANNEL POLLER 

The UNICHANNEL poller provides a mechanism for reporting to the user/ 
operator any error status conditions which may arise in the UNICHANNEL 
processor. Most of these are asychronous conditions not directly re- 
lated to any active XVM I/O requests. The poller, driven by the clock, 
periodically polls the UNICHANNEL with an error status report software 
directive to discover if any of these errors have occurred. 

The poller is triggered once per second by the clock interrupt routine. 
Barring the occurrence of certain delays, this means that the UNICHANNEL 
will be polled every second. One delay which can occur is slow response 
from the UNICHANNEL. Within reasonable limits this causes no problem. 
However, if the delay exceeds a preset timeout a separate error (des- 
cribed below) is reported. The other delay which might occur involves 
the state of the console terminal. UNICHANNEL poller errors are re- 
ported on the console terminal printer. If the console terminal printer 
is active, the poller will be deferred until it becomes idle. The 
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printer is considered active when either output is in progress or input 
is in progress and one or more characters have been typed. The printer 
becomes idle when the current .WRITE or .READ completes, which is usually 
at the end of the current line. 

When operating normally, the poller always has an error status report 
software directive request outstanding with the UNICHANNEL. When 
triggered, the poller checks if the directive has completed and exits 
(via a timeout check) if the directive is still in progress. Assuming 
the directive has completed, the poller scans for and reports any error 
conditions. Subsequently the poller requests a new error status report 
software directive for the next time it is invoked. 

Throughout its operation the poller places certain timeouts upon its 
UNICHANNEL interactions. Although not available as assembly parameters, 
there are several assembly constants which determine the lengths of 
the timeouts. These constants should be revised if the timeouts must 
be changed for any reason. 

The poller's primary timeout limits the time the UNICHANNEL has to 
respond to -the error status report software directive. This timeout, 
controlled by the constant PLR.WT, is normally set at one second. If 
this timeout expires, the poller will report an lOPSUC PRX 4 error. 
This error usually implies that the UNICHANNEL processor has halted 
or is otherwise locked out and unable to respond. 

The conditions which cause this timeout to take effect are frequently 
relatively long lasting. Therefore a frequency counter is used to avoid 
excessive repetition of the lOPSUC PRX 4 error message. This frequency 
counter is controlled by the constant PLR.FR, and will normally cause 
the lOPSUC PRX 4 message to repeat every five minutes. Note that the 
frequency counter only has effect if the UNICHANNEL processor lock out 
condition is continuously maintained. If the condition occurs, clears 
itself, and then re-occurs, the lOPSUC PRX 4 message will be immediately 
re-issued. 

In addition to the primary timeout described above, the poller imple- 
ments a second timeout. If the UNICHANNEL is unprepared to accept a 
TCB request when the poller attempts to issue an error status report 
software directive, an lOPSUC PRX 4 error is again reported. The poller 
implements this by neglecting to issue the request to the UNICHANNEL, 
so that eventually the primary timeout above expires. When the poller 
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Figure 3-5 
The Unichannel Poller 
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sinterrupts enabled. 



PLR.MS 



Attempt to check for 
and report lOPSUC 
, messages. 





Enable interrupts 
and return to TTA. 



PLR.FN 



Adjust poller time 
out (since the fol- 
lowing loop is not 
synchronized to the 
clock) . 



PLR.MS 



Attempt to check fo 
and report lOPSUC 

ssages. 




Poll the unichannel. / 



KEY 



Interrupts disabled 



Figure 3-5 (cent) 
The Unichannel Poller 
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PLR.ST 



Clear poller event 
variable. This sig- 
nifies that the error 
status report soft- 
wave directive has 
not yet completed. 



Initialize the pol- 
ler's time out to 
PLR.WT seconds (usu- 
ally one second) . 
Account for any loca- 
tion 7 overflow. 



No 


/Can the un 


1 channel \ 


\accept a TCB? / 


^ 


Yes 


^' 




Issue an error status 




report software di- 




rective to the uni- 




channel. 








\ 


' 



KEY 



Interrupts disabled 



Figure 3-5 (cent) 
The Unichannel Poller 
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issues its request, it has been running for some time with interrupts 
disabled, so that the UNICHANNEL processor has had a reasonable length 
of time to accept any earlier requests. 

The poller is implemented as a monitor appendage, so that it will only 
be included in the monitor when its operation has been enabled. It 
consists of the routines depicted in Figure 3-5. PLR.CK is called once 
per second from the clock interrupt routine. PLR.TT checks to see if 
the console terminal printer is active or idle. If the printer is 
active, PLR.PL will be called from TTA. when the printer next becomes 
idle. PLR.MS and PLR.ST together perform the polling function proper. 
PLR.ST is also used to initiate poller operation. PLR.FN is used to 
terminate poller operation. The poller must not be operating whenever 
a CAF instruction is executed. Note that the poller interacts with 
many other parts of the monitor, and thus much of the poller executes 
with interrupts disabled. 

3.5 XVM MODE 

The XVM/DOS resident monitor implements XVM mode (17 -bit indirect ad- 
dressing mode) by equating it to user mode. When running on an XVM, 
the monitor initialization code sets the relocate disable and 17-bit 
addressing flags. These flags are in the XM15 hardware option's MM 
register. The flags are also set whenever the monitor executes a CAF 
instruction. 

With these flags set, the monitor turns XVM mode on and off by switching 
between user and exec modes. Thus the .XVMON and .XVMOFF CAL's 
(Section 2.7) merely enter and leave user mode. User programs should 
not make use of this fact, however, as the detailed implementation of 
XVM mode m.ay change with subsequent releases of XVM/DOS. 
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CHAPTER 4 
THE NONRESIDENT MONITOR 

4.1 INTRODUCTION 

The System Loader brings the Nonresident Monitor into core after a 
hardware readin, a manual restart, a CTRL C, or a .EXIT. SGNBLK, 
SYSBLK and COMBLK are always coresident with the Nonresident Monitor. 
This gives the Nonresident Monitor access to all important system, 
parameters . 

The Nonresident Monitor announces its presence by typing XVM/DOS 
Vnxnnn on the teleprinter. It remains in core until the operator re- 
quests another system program, or until the operator's command implies 
a refreshed configuration of the Resident Monitor is necessary. 

The Nonresident Monitor's actions are limited to (1) decoding commands, 
(2) manipulating or examining bits and registers in .SCOM, .DAT, .UFDT, 
SYSBLK, COMBLK, and SGNBLK, and (3) calling the System Loader, when 
necessary. The Nonresident Monitor has only one entry, which starts 
an initialization section. Figure 4-1, Nonresident Monitor Initial- 
ization, describes that logic. Every tim.e the System Loader brings 
in the Nonresident Monitor, it passes control to the initialization 
section. After initialization, and after all commands that do not 
require the System Loader, the Nonresident Monitor types a $ and 
awaits an input line, terminated by a Carriage RETURN or an ALT MODE. 
It then examines the first six characters (or those up to the first 
blank) and tries to find an entry in the Nonresident Monitor's Command 
Table. If a match is found, control passes to the appropriate routine, 
and thence to the next command or the System Loader. If the typed 
command does not correspond to an entry in the command table, the 
Nonresident Monitor temporarily assumes the operator wishes a new 
core-image system program and checks COMBLK for a corresponding entry. 
If there is no corresponding entry in COMBLK, the Nonresident Monitor 
will type an error message and await the next command. If COMBLK 
contains a matching entry, the Nonresident Monitor composes a .OVRLA 
and passes control to the System. Loader via that .OVRLA. 
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START 



— ± . 

1. Bank bit initialize pointers to SYSBLK, COMBLK and SGNBLK 

2. Determine the number of positive .DAT slots 

3. Save the contents of .DAT-12, in case the user desires LP ON 

(restore before leaving Nonresident Monitor) 

4. Save contents of SC.FNM — Nonresident Monitor will use 
SC.FNM for address of LPA. or TTA. 

5. Change all .UFDT entries that equal BNK or PAG to SYS 

6. Compute addresses of .DAT-2,+1,+5 and +6 

7. Compute address of beginning of I/O Device Table in SGNBLK 



^ 




Restore .UFDT and 
.DAT to SGEN values 



Initialize ,DAT-2 and 
.DAT- 3 



<r 




Type out Nonresi- 
dent Monitor's name 




Request a date 



V 
vnexi. page; 

Figure 4-1 

Nonresident Monitor Initialization 
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(from preceding page) 
\^ 



Clear bit SC.NRE of 
SC.NMF (Nonresident 
Monitor .EXIT flag) 




Load BOSS 



■> 



>J^ 



Read command 
string 



(Continue to Command Decoder) 



Figure 4-] (Cont.) 
Nonresident Monitor Initialization 
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4.2 COMMANDS TO THE NONRESIDENT MONITOR 

This paragraph discusses legal commands listed in the Nonresident 
Monitor's Command Table. Table 4-1, Effects and Exits for Nonresident 
Monitor Commands, describes all commands that do not request a new 
program. 

There are five entries in the Command Table that load relocatable sys- 
tem programs. They are INSTRUCT, DDT, EXECUTE, GLOAD and LOAD. The 
Nonresident Monitor treats these commands separately, because SYSBLK 
does not list them. All information necessary for loading these pro- 
grams resides in the Nonresident Monitor itself. 

4.3 CONSIDERATIONS FOR ADDITIONS TO THE NONRESIDENT MONITOR 

Programmers should not attempt to add commands to the Nonresident 
Monitor unless they have access to a copy of the source code. The 
source code is available as an integral part of the XVM/DOS release. 
They should then use the EDITOR program to put in the indicated 
changes, and reassemble. 

New additions to the Nonresident Monitor require the following actions: 

1. Update the Nonresident Monitor's Command Table. 
The Command Table is in two parts: 

a) The .SIXBT names of the commands 

b) The corresponding transfer vector 

2. Write the code for the command. 

3. Consider the kind of exit the command v;ill take: 

a) Commands that end with a request for a new 
command should end with JMP KLCOM 

b) Commands that re-configure the Nonresident 
Monitor should end with JMP NRMEXl. 

4. Determine if the command should result in an automatic 
MODE typeout. If an automatic mode typeout is desired, a 
JMS SETMD should be included in the code for the command 
and a JMP NRMEXl exit should be used. 
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Table 4-1 



Effects and Exits 
for Nonresident Monitor Commands 



1 



COMMAND 


MODIFIER 


ACTION TAKEN 


EXIT 


API 


ON 
OFF 


Set bit SC.API of SC.MOD 
Clear bit SC.API of SC.MOD 


.EXIT 
.EXIT 


ASSIGN 


handler 

(and/or) 
uic 


Check whether handler is available. 
if yes, load .DAT slot with proper 
handler code. (The proper loader 
will load the handler, and insert 
its starting address into the .DAT 
slot. 

Load proper slot via a .USER 


Next 
Command 

Next 
Command 


BANK 


ON 

OFF 


Set bit SC.BNK of SC.MOD 
Clear bit SC.BNK of SC.MOD 


Next 
Command 


BATCH 


SY 
RK 
DP 
DK 
PR 
CD 
MT 


See Chapter 9. 




BUFFS 


number 


Put number indicated into SC.BNM, 
and set Nonresident Monitor Initial- 
ization to leave SC.BNM alone. 


Next 
Command 


CHANNEL 


7 
9 


Clear bit SC.9CH of SC.MOD 
Set bit SC.9CH of SC.MOD 


Next 
Command 


DATE 


date 
no date 


Enter date into SC.DAY 
Print date from SC.DAY 


Next 
Command 


FILL 


ON 
OFF 


Set bit SC.FIL of SC.MOD 
Clear bit SC.FIL of SC.MOD 


.EXIT 
.EXIT 


GET 
GETP 
GETS 
GETT 




See Section 2.8. 




HALF 

i 


ON 
OFF 


Set bit SC.HFN of SC.VTF 
Clear bit SC.HFN of SC.VTF 


.EXIT 
.EXIT 


HALT 




Set bit SC.HLT of SC.NMF 


Next 
Command 



1 



This table assumes error-free input 
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Table 4-1 (cont) 

Effects and Exits 
for Nonresident Monitor Commands 



COMMAND 



MODIFIER 



ACTION TAKEN 



EXIT 



INSTRUCT 



none 
ERRORS 



Print INSALL SRC 
Print INSERR SRC 



By loading 
INSTRC BIN 



-EXIT 
Command 



KEEP 



ON 
OFF 



Set bit SC.KPN of SC.NMF 
Clear bit SC.KPN of .SC.NMF. Init- 
ialize to SGEN default values all 
entries in .DAT and .UFDT, except 
change SCR default values to cur- 
rent UIC. 



Next 
Command 



LOG 



Output five spaces after Carriage 
RETURNS. After ALT MODE, go to 
next command. 



Next Com- 
mand (after 
ALT MODE) 



LOGIN 



uic 



Make specified UIC current (SC.UIC) . 
*Then set up .UFD entries; set .DAT 
entries and system parameters (SC.MOD, 
SC.MSZ, SC.BNM, SC.VTF) to system de- 
fault values; clear SC.NMF and SC.TLM. 



.EXIT 



LOGOUT 



Set current UIC to SCR. Then same 
as LOGIN (above) from *. 



,EXIT 



LOGW 



For BOSS-15, print message. In all 
cases, after a Carriage RETURN, out- 
put five spaces. After ALT MODE, 
type four bells +P, and await CTRL P, 
After CTRL P, go to next command. 



Next com- 
mand (after 
ALT MODE) 



LP 



ON 
OFF 



Set bit SC.LPON of SC.NMF. 
Clear bit SC.LPON of SC.NMF. 



.EXIT 
.EXIT 



MEMS I Z 



nnnk 



Check nnn for multiple of 8 and 
range 2 4£nnn£l2 8, if valid (nnn* 
1024)-1 is stored in SC.MSZ. 



.EXIT 



MICLOG 



mic 



Check mic with SGNBLK. If correct 
set bit SC.MIC of SC.NMF and make 
'SYS' the current UIC. Then same 
as LOGIN (above) from * (except 
SC.NMF not cleared). If incorrect, 
ignore command. 



.EXIT 



MODE 



Information pertaining to available 
hardware (SC.NMF) is compared with 
requested parameters and the result- 
ing parameter settings are typed to 
the console for those parameters 
related to the existing hardware. 



Next 
Command 



PAGE 



ON 



Clear bit SC.BNK of SC.MOD, 



EXIT 



Table 4-1 (cont) 

Effects and Exits 
for Nonresident Monitor Conmiands 



COMMAND 


MODIFIER 


ACTION TAKEN 


EXIT 


POLLER 


ON 
OFF 


Clear bit SC.PLR of SC.MOD. 
Set bit SC.PLR of SC.MOD. 


.EXIT 


PROTECT 


n 


If n is between and 7, inclusive, 
enter it into SC.PRC. 


Next 
Command 


PUT 




See Section 2. 8. 




QDUMP 




Set bit SC.DMP of SC.NMF. 


Next 
Command 


REQUEST 


none 
USER 
prog 


Print the current assignments for 
.DAT and .UFDT. 

Print the current assignments for 
all positive .DAT and .UFDT slots. 

Print required .DAT and .UFDT slots, 
and the assignments and use for 
each. 


Next 
Command 


SCOM 1 

1 

1 


Print the information for the cur- 
rent system. 


Next 
Command 


TAB 


ON i Clear bit SC.TAB of SC.MOD. 
OFF 1 Set bit SC.TAB of SC.xMOD. 


.EXIT 
.EXIT 


TIME 


time 
none 


Enter time into SC.TIM. 
Print time from SC.TIM. 


Next 
Command 


UC15 


ON 
OFF 


Bit SC.UC15 of SC.MOD is set in- 
dicating a request for UNICHANNEL 
interaction capability. (Note: 
the resident monitor verifies the 
validity of this request.) 

Bit SC.UC15 of SC.MOD is cleared 
indicating that no UNICHANNEL inter- 
action is desired. (The resident 
monitor will not allow UC15 OFF to 
succeed on an RK based system.) 


.EXIT 
.EXIT 


VT 


ON 
OFF 


Set bit SC-VTN of SC.VTF. 
Clear bit SC.VTN of SC.VTF. 


.EXIT 
.EXIT 


XVM 


ON 
OFF 


> Bit SC.XVM of SC.MOD is set indi- 
! eating a request for wide address- 
ing mode. (Note: the resident 
monitor verifies the validity of 
this request. ) 

Bit SC.XVM of SC.MOD is cleared 
indicating that 15-bit indirect 
addressing mode is desired. 


.EXIT 
.EXIT 
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5. After assembly, the programmer must call PATCH, in order 
to make his relocatable binary program absolute. Commands 
to PATCH should be as follows : 

>D0S15 J 

>READR 16077 DOSNRM BINV 

16077 indicates the highest location the new monitor can 
occupy. (SYSBLK begins at 16100.) DOSNRM BIN happens to 
be the file name used by program development. The pro- 
grammer may, of course, substitute his own file name. 
More information may be found in the PATCH manual. 
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CHAPTER 5 
THE SYSTEM LOADER 

The System Loader is the third major part of the XVM/DOS operating 
system. The other two are the Resident and Nonresident monitors. The 
Resident and Nonresident Monitors communicate with the System Loader 
by manipulating certain .SCOM registers. When commands to either part 
imply a new configuration is needed, that part sets up the appropriate 
•SCOM registers and passes control to the resident monitor via a .EXIT 
or .OVRLA. The resident monitor rebuilds itself, loads the System 
Loader into high core, and gives it control. 

The System Loader examines the .SCOM registers then loads the desired 
system program and all handlers required by the new configuration. In 
addition, it will allocate all required buffers. The Nonresident Mon- 
itor is treated like any other core-image system program. 

The System Loader never loads user programs. It only loads core-image 
system programs, the INSTRUCT command processing program, the Linking 
Loader and Execute. The latter two load user programs. 

The System Loader uses two device handlers to interface with the disk: 
the System Bootstrap, and the System Loader Disk Handler (DKL./DPL./ 
RKL.). xxL. arrives in core as part of the loader itself. The Boot- 
strap loads core-image programs only. The xxL handler takes care of 
relocatable programs and any handlers loaded by the System Loader. 
Those include all handlers for core-image system programs, the Linking 
Loader's own handlers, and any needed by the Execute file. The Link- 
ing Loader loads handlers needed by user programs it links. 

5.1 LOADING SYSTEM PROGRAMS 

The System Loader gets control in the highest bank. The System Loader 
loads handlers from the lowest part of free core up. Core-image sys- 
tem programs are usually loaded just beneath the Bootstrap. Such core 
images must be wholely within the bank in which the Bootstrap resides, 
and above register 17 of that bank. Figure 5-1 illustrates the core 
maps for system programs . 
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Whenever the Linking Loader is loaded (LOAD, GLOAD, DDT, and DDTNS) , 
the System Loader loads all handlers for .DAT slots -1, -4, and -5, 
and then loads the Linking Loader itself. (DDT is loaded by the Link- 
ing Loader.) Whenever INSTRC (the INSTRUCT command processing program) 
is loaded, the handler assigned to .DAT slot -12 is also loaded. Fig- 
ure 5-2 illustrates the core maps for the Linking Loader and INSTRC. 

For EXECUTE, the System Loader loads EXECUTE'S handler, and reads the 
EXECUTE file, in order to determine the active .DAT slots. The Sys- 
tem Loader then loads all the handlers required and sets up the .DAT 
slots. Figure 5-3 illustrates core maps for EXECUTE. 

BOSS XVM mode operation requires the system "A" handler be assigned to 
.DAT-7. This requires a slight of hand on the part of the System 
Loader, which needs the "L" handler on .DAT-7. It therefore loads 
the "A" handler as if it were assigned to .DAT+J2f, and transfers the 
set up .DAT+0 contents to .DAT-7 before transferring control to the 
program being loaded. . DAT+J? is then restored to its original status. 

5.2 TABLES AND INFORMATION BLOCKS USED AND BUILT BY LOADERS 

The System Loader uses SYSBLK, COMBLK, SGNBLK, .SCOM, the Mass Storage 
Busy Table, the File Buffers Transfer Vector Table, the Overlay Table, 
•DAT, and .UFD. Tables 5-1 and 5-2 describe how the Loaders use these 
blocks and tables. 

5.3 .DAT SLOT MANIPULATION BY THE SYSTEM LOADER 

When loading core-image system programs, the System Loader determines 
the active .DAT slots by examining COMBLK. When loading EXECUT, the 
System Loader sets up .DAT-4, and any active slots indicated by the 
Execute file itself. When loading the Linking Loader, the System 
Loader sets up .DAT-1, -4, and -5 and also .DAT-12, if loading INSTRC. 
The Linking Loader will set up other active .DAT slots according to 
the . lODEV commands in the assembly of the program units being loaded. 

Both the System Loader and the Linking Loader set up .DAT slots in 
this manner: (In the following procedure, "loader" refers to either 
one. ) 
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BOOTSTRAP 



SYSTEM PROGRAM* 
(THIS AREA IS USED BY CORE 
IMAGES. SOME ROOM UNDERNEATH 
THE BOOTSTRAP MAY BE LEFT 
FREE FOR COMMUNICATION 
BETWEEN CORE IMAGES IN AN 
OVERLAY STRUCTURE. 
CORE IMAGES MUST BE 8K OR 
LESS.) 



HANDLERS, BUFFERS 



BUFFER POOL 
TRANSFER VECTORS 



OVERLAY TABLE 



DEVICE TABLE 



RESIDENT MONITOR 



24K,32K 



SC.FRL+1 
SC.FRL 



SC.RMS 



Figure 5-1 

System 
Program Load 



*A11 system programs 
except MACll, which 
is always loaded in 
Bank 1. 



BOOTSTRAP 



DDT, IF PRESENT 



LOADED PROGRAMS 

ON DDT LOADS, SYMBOLS 
ARE MOVED INTO THE 
LOWEST PART OF FREE CORE. 

SYMBOL TABLE 
SYMBOLS AND PROGRAMS BUILD 
TOWARD EACH OTHER. 



BUFFER POOL 



BUFFER POOL 
TRANSFER VECTORS 



RESIDENT MONITOR 



24K,32K 



SC.FRL 



SC.RMS 



BOOTSTRAP 



OVERLAY SYSTEM 
BLANK COMMON 



FREE CORE 



ALL HANDLERS REQUIRED 



BUFFER POOL 



RESIDENT MONITOR 



Figure 5-3 
Execute 



Placement of SC.FRL 
depends on relative 
positions of the 
Linking Loader and 
its handlers. When 
control is trans- 
ferred to loaded 
program SC.FRL and 
SC.FRL+1 bracket 
free core. 



24K.32K 

SC.FRL+1 

SC.FRL 
SC.RMS 



Figure 5-2 
Linking Loader 



Table 5-1 
Tables and Blocks Used by the Loaders 



NT^J^ 



SYSBLK 



COMBLK 



SGNBLK 



.SCOM Table 



Mass Storage 
Busy Table 



File Buffers 
Transfer Vec- 
tor Table 



Overlay 
Table 



.DAT 
and 

• UFDT 



USE 



The System Loader obtains Monitor 
TRAN parameters from SYSBLK when 
it builds 



Indicates number of buffers re- 
quired, the active .DAT slots, 
and the names 



Number of words per buffer and 
handler information. 



See Table 5-2 



Built by the System Loader itself 



Built by the System Loader itself 
System Loader proper initializes 
for core-image programs. 



Built by the System Loader itself 



The System Loader loads all hand- 
lers for core-image programs and 
and EXECUTE Files, and sets up 
the appropriate .DAT slots. The 
System Loader also loads handlers 
assigned to .DAT-1, -4, and -5 
when loading the Linking Loader, 
and .DAT-7 and +6 for BOSS XVM. 



LOCATION 



165!3rj2f of 
.SYSLD's bank 



171J2f0 down, in 
.SYSLD's bank 



161j2f0 of 
.SYSLD's bank 



100 of 1st bank 



Pointed to by 
SC.BTA 



Pointed to by 
SC.BTB 



Pointed to by 
SC . 0TB 



Pointed to by 
SC.DAT and 
SC.UFD 



R-4 



Location 



SC.SST 



SC.UST 



SC.FNM 



SC.FNM+1 



SC.FNM+2 



SC.BNM 



SC.BLN 



SC.BTB 



SC.OTB 



SC.SPN 



SC.ACT 



SC.BTA 



Table 5-2 
.SCOM Registers Used by the System Loader 



Description of Use by the System Loader 



SC.FRL .SYSLD continually updates this indication of the 

first free location as it moves code and builds 
tables. 

SC.FRL+1 Updated as with SC.FRL. Last free location in core 
below the Bootstrap. 



.SYSLD uses SC.SST for the starting address when 
loading EXECUT or LOAD. The Bootstrap transfers 
to the address in SC.SST after all its operations 



Stores codes for DDT, DDTNS , LOAD and GLOAD. 



.SYSLD saves contents of .DAT-1 in SC.FNM, when 
loading the Linking Loader. When loading EXECUT, 
SC.FNM contains the first three-characters of the 
Exedute file's name. Contains .DAT-12 when loading 
Nonresident Monitor. 



.SYSLD saves contents of .DAT-4 in SC.FNM+1, when 
loading the Linking Loader. VJhen loading EXECUT, 
SC.FNM+1 contains the second three characters of 
the Execute file's name. 



.SYSLD saves contents of .DAT-5 in SC.FNM+2, when 
loading the Linking Loader. When loading EXECUT, 
SC.FNM+2 contains the extension of the Execute 
file's name. 



When the Nonresident Monitor was the last program, 
the System Loader allocates the number of buffers 
indicated by the contents of SC.BNM. If the Non- 
resident Monitor was not the last program, the Sys- 
tem Loader restores SC.BNM to the default value if 
program to be loaded is core image. Otherwise, un- 
touched. 



The number of words per file buffer. 



Pointer to the File Buffer Transfer Vector Table, 



When loading a core-image program, .SYSLD loads 
SC.OTB with the pointer to the Overlay Table, or 
with zero, if there is none. 



Contains name of the program to be loaded. 



System Loader loads with the number of entries in 
the Mass Storage Busy Table. 



System Loader loads with the address of the first 
entry in the Mass Storage Busy Table. 
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1. Each .DAT slot will contain a handler number — either the 
system default, or one inserted via an ASSIGN command to 

the Nonresident Monitor. This handler number is the relative 
index of the handler name in the handler table portion of 
SGNBLK. 

2. For each active .DAT slot, the loader uses the handler num- 
ber in that slot to find the name in the handler table, and 
converts the name to .SIXBT. 

3. If the handler is already in core, the loader simply inserts 
the starting address of the handler into the .DAT slot. 

4. If the handler is not yet in core, the loader does a .SEEK 
to <IOS> UIC for the handler, reads it into core, relocates 
it, and places the starting address of the handler into the 
.DAT slot. 

The System Loader always sets up .DAT-2 and -3. (It reserves .DAT-7 
for its own use.) When not in non-BOSS Batch Mode, -2 is assigned to 
TTA. In non-BOSS Batch Mode, the batch input device goes to -2. If 
loading the Nonresident Monitor and bit SC.LPON of SC.NMF is set, the 
System Loader will set up .DAT-12 for LPA, if it is in the system, or 
else for TTA. If in BOSS mode, the Nonresident Monitor assigns LPA. 
to .DAT+6, and the System Loader assigns .DAT-7 to the system device 
"A" handler. The System Loader then ensures that both handlers are in 
core. The Resident BOSS setup routine subsequently routes all .DAT 
slots connected to TTA. to Resident BOSS. 

5.4 BUFFER ALLOCATION BY THE SYSTEM LOADER 

The System Loader allocates space for buffers equal to the contents 
of SC.BNM times the contents of SC.BLN. The first time initialization 
routine sets SC.BLN to the standard number of locations per buffer. 
Before the Nonresident Monitor does an .OVRLA to a software system 
program, it checks whether a BUFFS command has been issued. If so, 
it leaves SC.BNM as is. If not, it uses the default number of buffers 
for that program, as shown in SYSBLK. 



CHAPTER 6 
SYSTEM INFORMATION BLOCKS AND TABLES 

6.1 SYSTEM COMMUNICATION (.SCOM) TABLE 

The system communication or .SCOM table is at a fixed location in mem- 
ory. It is the primary means of communication between the components 
of XVM/DOS. Individual .SCOM locations may either be reconstructed 
for each core load or preserved across successive core loads. Table 
6-1 describes the .SCOM table. 

The accompanying table defines mnemonics for each .SCOM location, and 
separate mnemonics for any bit flags. These mnemonics should be used 
for all references to .SCOM. The mnemonics should be equated to the 
appropriate values and then used whenever .SCOM is accessed to make 
the program easier to read and .SCOM easier to alter in the future. 



6.2 DISK-RESIDENT UNCHANGING BLOCKS: SYSBLK, COMBLK AND SGNBLK 

SYSBLK, COMBLK and SGNBLK occupy blocks 34, 35, and 36 (octal) on the 
system device (unit zero). SYSBLK and COMBLK (blocks 34 and 35) contain 
the parameters for loading all core image system programs. SGNBLK 
contains all the other information needed to run DOS. All three arrive 
in core along with the Resident Monitor and start at location 1615?0 of 
the highest bank. The Nonresident Monitor and System Loader use them; 
SGEN XVM and PATCH XVM modify them when necessary. 

6.2.1 SYSBLK 

SYSBLK contains the parameters required for implementation of .OVRLA 
to any system program, or any of the system program overlays. 

The order of entries in SYSBLK is unimportant, except for the first 
three permanent entries: RESMON, .SYSLD, and tQAREA. The first word 
of SYSBLK contains the block address (the unrelocated address) of the 
first free word after itself. Figure 6-1 describes SYSBLK. 
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Table 6-1 
System Communication (.SCOM) Table 



Location 


Mnemonic 


Description 


100 


SC.COD 


First free register below boot- 
strap; the highest location use- 
able for code. 


101 


SC.RMS 


Resident Monitor size; first free 
register above Resident Monitor. 


102 
103 


SC.FRL 
SC.FRL+1 


Free memory in low core (below 
the bootstrap) . SC.FRL contains 
the address of the first free 
location. SC.FRL+1 contains the 
address of the last free location. 


104 


SC . MOD 
•'^" SC.API = 400000g 
• SC.TAB = lOOOOOg 
V ; SC.NRM = 40000g 

SC.UB2 = 20000g 
SC.UBl = lOOOg 
SC.9CH = 4000o 

9 

. ' SC.FIL = 200 g 
', - SC.BNK = 10 Og 
SC.LPSZ = 60g 

SC.PLR = 4o 
o 

SC.UC15 = 2g 
SC.XVM = Ig 


Operating mode bit register: 

1 -»- API enabled 

1 -> Simulate tabs with spaces 

1 ->■ Non-resident monitor in 
core 

Reserved for customer use. 

Reserved for customer use. 

1 -^9-channel magtapes assumed. 

1 -»- Insert fill characters. 

1 ^ Bank mode operation. 

Line printer line length (in 
characters) : 

-y zero 40 ->- 120 
20^80 £9^132 

1 -> Poller enabled. 

1^ UC15 enabled. 

1 -» XVM mode enabled. 


105 


SC.SST 


Core image system program start- 
ing address. 


106 


SC.UST 

SC.DDT = 400000o 
o 

SC.GLD = 2OOOOO0 
8 

SC.DNS = lOOOOOg 

Bits 3-17 contain the user 
which is also the address c 
ter routine. 


User program starting address/fS 
address. 

1 -»■ DDT in core. 

1 -^Linking Loader invoked via 
GLOAD. 

1 -> DDT invoked without symbol 
table (via DDTNS) . 

program starting address, 
f the fS control charac- 



6-2 



Table 6-1 (cont) 
System Communication ( . SCOM) Table 



Location 


Mnemonic 


Description 


107 

110 
111 


SC.FNM 

SC.FNM+1 
SC.FNM+2 


Execute Filename, .GET,. PUT File- 
name, or linking loader handler 
indices. 


112 


SC.LV4 


API level 4 software interrupt 
transfer vector. 


113 


SC.LV5 


API level 5 software interrupt 
transfer vector. 


114 


SC.LV6 


API level 6 software interrupt 
transfer vector. 


115 


SC.LV7 


API level 7 software interrupt 
transfer vector. 


116 


SC.TTP 


Saved PC on control character 
interrupts. 


117 


SC.TTA 


Reserved. 


120 


SC.MSZ 


System memory size, as set via 
MEMS I Z command. 


121 


SC.MTS 


Magtape status register. 


122 


SCAMS 


Actual (physical) memory size. 


123 


SC . DAT 


Address of .DAT table. 


12 4 


SC.SLT 


Number of positive .DAT slots. 


125 


SC.UFD 


Address of .UFD table. 


126 


SC.BNM 


Number of file buffers. 


127 


SC . BLN 


Number of words per file buffer. 


130 


SC.BTB 


Address of file buffer transfer 
vector table. 


131 


SC.OTB 


Address of overlay table or zero. 


132 


SC.BBN 


Bad block number for IOPS20 and 
I0PS21. 
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Table 6-1 (cont) 
System Communication (.SCOM) Table 



Location 


Mnemonic 


Description 


133 


SC . VTF 

SC.HFN = 400000o 
o 

SC.VTN = lOOOOOg 
SC.DMN = Ig 


VT ON flag register; 

1 -»-Half size VT15 buffer 
(HALF ON) . 

1^ VT ON issued. 

1 ^ Display mode on. 


134 


SC.ETS 


Elapsed time in seconds. 


135 


SC.CTT 


Instruction to clear teletype busy 
switch. 


136 


SC.ACT 


Number of active .DAT slots; 
number of entries in mass storage 
busy table. 


137 


SC.EEP 


Expanded error processor entry 
point. 


140 


SC.EEP+1 


JMP to expanded error processor. 


141 


SC.UIC 


Current UIC 


142 


SC.NMF 
SC.MIC = 400000g 
SC.NRE = 200000g 
SC.NRO = lOOOOOg 
SC.LPON = 40000g 
SC.DMP = 2 00 00 g 
SC.HLT = lOOOOg 
SC.TMM = 4000g 
SC.PVT = 1000 g 
SC.PCLK = 400g 
SC.PAPI = 200 g 
SC.PUC15 = lOOg 
SC.PXVM = 40g 
SC.DT6 =103 
SC.DT7 = 4g 

SC.KPN = 2g 
SC.BCH = Ig 


Non-resident monitor flag register: 

l^MICLOG successful 

1 -> Non-resident monitor .EXIT 

1 ^^ Non-resident monitor .OVRLA 

1 ->LP ON ^LP OFF 

1 -> f Q dump on lOPS errors. 

l->Halt on lOPS errors. 

1^-Mode message should be typed. 

1 ^VT15 present. 

1 ->■ Real time clock present. 

1 ->- API present. 

1 ->^ UC15 present. 

1 ^XVM present. 

1-^Set up .DAT+6 (for BOSS). 

l->Set up .DAT-7 (for BOSS or 
Batch) 

1 ^ KEEP ON ^ KEEP OFF 

1 ->■ Batch or BOSS mode 
active . 
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Table 6-1 (cont) 
System Communication (.SCOM) Table 



Location 


Mnemonic 


Description 


143 

144 


SC.SPN 
SC.SPN+1 


.SIXBT name of system program to 
to loaded. 


145 
146 


SC.NMN 
SC.NMN+1 


.SIXBT name of the non-resident 
monitor ("DOS 15") . 


147 


SC.DAY 


Today's date, formatted as MMDDYY. 


150 


S C.TIM 


The current time , formatted as 

HHMMSS. 


151 


SC.ETT 


Elapsed time in ticks. 


152 


SC.BOS 

SC.BMD = 4OOOOO0 


SC.BCR = 200000g 

SC.BEOF = lOOOOOg 

SC.BTM = 4OOOO0 


SC.BTT = 20000 
SC.BIO = lOOOOg 
SC.BDMP = 4000g 

SC.BOA = 2000g 

SC.BJA = lOOOo 


SC.BXT = 400o 


SC.BPT = 200g 
SC.BGT = lOOg 
SC.BERR = 16g 
SC.BAB = Ig 


BOSS bit register: 

1 ->- BOSS mode active. 

1 -> Control card read by user. 

1 -^ EOF reached on run time file. 

1 ^ Time estimate exceeded. 

1 ^ I/O CAL to go to TTA. 

l-> Terminal lOPS error. 

1 -^Give user +Q dump on lOPS 
errors. 

1 -^ Operator abort (+T) 

1 -> Job active. 

1 ^ Exit from BOSS mode. 

1 ^ User tried to do a .PUT 

1 ^ User tried to do a .GET 

.SYSLD error number. 

1 -^ Job abort. 


153 


SC.VTR 


VT ON display file restart address 
or zero if display file not set up. 


154 


SC.PRC 


Default file protection code. 


155 


SC.TRN 


Reserved. 


156 


SC.TLM 


Two's complement of time limit in 
seconds or zero if no time limit. 


157 


SC.SDV 


Handler index of system device for 
Linking Loader. 
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Table 6-1 (cont) 
System Communication (.SCOM) Table 



Location 


Mnemonic 


Description 


160 


SC.TMT 


Two's complement of number of 
clock ticks until .TIMER inter- 
rupt. 


161 


SC.TMA 


.TIMER interrupt routine entry 
point address. 


162 


SC.BTA 


Address of mass storage busy table. 


163 


SC.BTL 


Number of words per mass storage 
busy table entry. 


164 




Reserved 


165 


SC.CQF 
SC.QFLG = 400000g 

SC.QNF = 2000 

SC.QNRM = 1000„ 
o 

SC.QPUT = 400g 
SC.QRTN = 7g 


.GET/. PUT flag register (for 
communication with QFILE) : 

1 -^ Call QFILE 

-> Return from .PUT 

l->Skip file transfer operation. 

1 -»-Exit to non-resident monitor 

when QFILE completes. 

1 -> Transfer 4Q area to file 
->■ Transfer file to +Q area 

.PUT/. GET return code. 


166 
167 

170 


SC . CQB 
SC.CQB+1 

SC.CQB+2 


.MTRAN parameter block for fQ 
area contains: 

First block of fQ area 

First address -1 in core 

Two's complement transfer length 

The transfer length is the mini- 
mum of the fQ area size and the 
current system memory size. 


171 


SC.TDT 


Tomorrow's date, formatted MMDDYY. 


172 




Reserved. 


173 


SC.TMR 


Two's complement of the number 
of ticks left in this second. 


174 


SC.LFR 


Two's complement of the number of 
ticks per second. 


175 


SC.RTF 


Indicates the current position 
within the batch stream, (batch 
mode) or the run time file (BOSS 
mode) . 
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Table 6-1 (cont) 
System Communication (.SCOM) Table 



Location 


Mnemonic 


Description 


176 
177 


SC.FRH 
SC.FRH+1 


Free memory in high core (above 
the bootstrap). SC.FRH contains 
the address of the first free 
location. SC.FRH+1 contains the 
address of the last free location. 


200 


SC.TCB 


Address of Task Control Block 
transfer vector table. 


201 


SC.UOl 


Reserved for customer use. 


202 


SC.U02 


Reserved for customer use. 


203 


SC.U03 


Reserved for customer use. 


204 


SC.U04 


Reserved for customer use. 


205 


SC.U05 


Reserved for customer use. 


206 
207 


SC.BFNM 
SC.BFNM+1 


.SIXBT batch stream filename or 
zero if batch device is non-file 
oriented. 


210 


SC.BFXT 


•SIXBT batch stream file extension. 


211 


SC.BUIC 


.SIXBT batch stream file UIC code. 


212 


SC.BDEV 


.SIXBT batch stream device 
mnemonic. 


213 


SC.BUNT 


Batch stream device unit number 
(high 3 bits) . 
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Word # 





7N+1 




7N+2 


s 


7N+3 


Y 


7N+4 


S 




B 


7N+5 


L 


7N+6 


' K 


7N+7 



Value 
J2f00nnn 

.SIXBT 
.SIXBT 
nnnnnn 

j?00j2fnn 

addres 

0nnnnn 
addres 



Description 

Pointer to first free word after SYSBLK 
(There is one set of seven words/core 
image program. ) 

Name of System Program or overlay 

Number of first block on system device 
occupied by this program or overlay. 
Number of blocks occupied by this pro- 
gram or overlay 

Thirteen-bit first address for this 
program or overlay 
Program size 

Thirteen-bit starting address for this 
program or overlay 



(free area] 



i C 
O 
M 
B 
L 
K 



mmm 

mmm+1 
mmm+2 
mmm+3 
mmm+4 
mmm+5 



mmm+6 
mmm+7 

mmm+10 

mmm+11 
mmm+1 2 
mmm+13 



mmm+14 



777 



000010 

.SIXBT 
.SIXBT 
.SIXBT 
.SIXBT 



.DAT&777 
.DAT&777 

000005 

.SIXBT 
.SIXBT 
000001 



.DAT&777 



000500 



Number of words in this entry (in this 
case, 10) 

Name of this system program (left- 
justified and zero-filled) 
Name of an overlay (left- justified and 
zero-filled) — overlays are optional 
Number of buffers required by this sys- 
tem program (Bits 0-6 = means the 
end of any overlay names. This is why 
program and overlay names must be left- 
justified. ) 
Active .DAT slot 

Active .DAT slot (Note: 777777 for a 
.DAT slot means all positive .DAT slots, 
Number of words for this entry (in this 
case, 5) 

Name of this system program 

Number of buffers required by this pro- 
gram (Note that this program, has no 
overlays. ) 
.DAT slot for this program 



Pointer to first word in COMBLK. The 
two contiguous blocks on the system 
device that hold SYSBLK and COMBLK 
are treated by the system as one large 
block. 



Figure 6-1 
SYSBLK and COMBLK 



6.2.2 COMBLK 

COMBLK contains information the System Loader and the Nonresident Mon- 
itor need to remember about the current core-image system programs. 
The last location in COMBLK (that is, location 377 of block 35) con- 
tains the block address of the first entry in COMBLK. The remainder 
of COMBLK consists of variable-length entries associated with the sys- 
tem programs. The Nonresident Monitor searches COMBLK when it finds 
no match for a typed command in its own Command Table. Figure 6-1 
illustrates the organization of COMBLK. SGEN XVM adds names of core- 
image system programs by making them the new first entry. In this way, 
SYSBLK and COMBLK build toward the center. 

6.2.3 SGNBLK 

SGNBLK (block 36 on the system device) contains all the system param- 
eters not directly associated with core-image system programs. The 
bulk of SGNBLK is concerned with I/O (.DAT slots, .UFDT slots. Skip 
Chain Order, Handlers, and skip lOT codes and mnemonics) . The first 
few registers hold such important system information as the system de- 
vice, SC.MOD contents, and so on. The very first word in SGNBLK points 
to the block address of the first free word after SGNBLK. The next 
entry is an offset word indicating the total length (including itself) 
of the miscellaneous system parameter table to follow. This table 
includes the size of the .DAT and the size of the skip chain. The end 
of the handler and skip lOT table is the first free entry of the block. 

The .DAT slot table corresponds to the legal range of .DAT slots, with 
the maximum negative set to 15g and the maximum positive set to a num- 
ber not to exceed 77 „. The .DAT slots are in the form in which they 

o 

appear when the Nonresident Monitor is in core. That is, the unit 
number is in bits 0-2, and the niimber of the handler right-justified 
in bits 3-17. The handler number for the first handler in the Device 
Handler-Skip lOT Table is zero, for the pseudo-handler NON , TTA. is 
one, and so on. The constant 100000 indicates a fixed or illegal .DAT 
slot (such as -2, -3, and 0). DOSGEN will not modify such slots. 

The .UFD Table is in one-to-one correspondence with the .DAT slot Table, 
An entry of .SIXBT 'UIC indicates that the logged in UIC is to be sub- 
stituted for the name UIC in the table. An entry of .SIXBT 'SYS' in- 
dicates BNK or PAG is to be substituted, in accordance with the current 
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addressing mode. Otherwise, the contents of each location will be the 
.SIXBT representation of the corresponding . UFD slot. 

The Skip Chain Table lists the system skip lOT's in order. A negative 
skip (one that skips on "off", not "on") is represented in one's com- 
plement. Not all skips in the handler Skip lOT Table (described below) 
need to be included in the Skip Chain Table. 

The Device Handler/Skip lOT Table contains all the handler names and 
skip lOT numbers and mnemonics for each I/O device identified to the 
system. Every such device has an entry in the table. A handler name 
must be exactly three characters in length, with the last character 
not an octal digit. The device code for a device is exactly two char- 
acters. The first two characters of each handler name for a device 
must be the device code. This fact is essential for understanding the 
format of a device entry, since the device code is never stored as such 
in an entry, but is inferred from the device handler name. The typical 
entry for a device is the following: 

1. The first words of an entry contain the handler names for a 
device in .SIXBT. Each handler name is different, and the 
end of the list of handlers is determined by a word with zeros 
in bits 0-5 (the first character position) . 

2. The word that terminated the list of handler names contains 
the number of skip lOT's for the device. For each skip lOT, 
there are three words in the table: two for the skip mnemonic 
and one for the actual code. 

The next device entry follows the last skip for the previous device. 

Handlers may be entered without any skips, and skips m.ay be included 

for handlerless devices. Figure 6-2 illustrates the organization of 
SGNBLK. 

6.3 DISK- RESIDENT CHANGING BLOCKS 

The System Loader uses block 37 of the system device to store an image 
of .DAT and .UFDT. Other disk-resident changing blocks are the storage 
Allocation Table and the Bad Allocation Table. These tables are de- 
scribed in Chapter 7. 
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Location 



3 

4 
5 
6 
7 

10 
11 
12 
13 
14 
15 



Value 



mnn 
000015 
ifnnn 



mnn 
nnnnnn 
nnnnnn 
nnnnnn 
nnnnnn 
nnnnnn 
.SIXBT 
nnnnnn 
00000n 
00nnnn 
7777nn 



mnn 
.SIXBT 



.SIXBT 
nnnnnn 



nnnnnn 
.SIXBT 



.SIXBT 
000003 
nnnnnn 
nnnnnn 
nnnnnn 
.SIXBT 
000001 
nnnnnn 



nnn 



Description 

Pointer to first free entry in SGNBLK 
Number of miscellaneous parameters 
Size of .DAT plus size of .UFD = (number of 
positive .DAT slots + 16g)*2. (Initial value 
is 208 positive .DAT slots.) 
Number of skips in Skip Chain 
System device code in .SIXBT 
Original contents of SC.MOD 
Original contents of SC.MSZ 
Number of words per buffer (SC.BLN) 
Default number of buffers (SC.BNM) 
Monitor Identification Code 
Information on VT and CTRL X (SC.VTF) 
Default files protection code (SC.PRC) 
Size of the Resident Monitor Patch Area 
Minus the number of clock ticks in a second 
(-74 for 60 hz , -62 for 50 hz) 



Device assignments for the .DAT (made by 
handler numbers) . 



UIC assignments for the UFD. 



Skip Chain Table (Negative skips in one's 
complement) . 



The last part of the SGNBLK is the Device 
Handler-Skip lOT Table. Each entry starts 
with the .SIXBT representations of all 
handlers for a particular device. (First 
two characters equal device code, for all 
handlers.) Zeroes in the first six bits of 
a word indicates the end of the handler 
names , and says that the rest of the word 
contains the number of skips for this 
entry's device. The skip lOT's follow im- 
mediately. As above, one's complement 
skips indicate negative skips. Note, how- 
ever, the confusing fact that a one's com- 
plement of a skip lOT is a positive number. 
Thus, 70nnnn complemented is 07nnnn. 



Figure 6-2 
SGNBLK 
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6.4 TEMPORARY TABLES BUILT FROM DISK-RESIDENT TABLES 

6.4.1 The Overlay Table 

The System Loader builds the Overlay Table from the entries in SYSBLK 
referenced by a core-image system program entry in COMBLK. That is, 
the Overlay Table contains an entry for the system program itself, and 
one for each of its overlays. Table 6-2 illustrates the format of an 
entry in the Overlay Table. The first entry in the Overlay Table is 
pointed to by SC.OTB. SC.OTB will contain zero, if there are no 
entries in the Overlay Table. This will occur during Linking Loader 
or EXECUTE loads. The overlay table is terminated by a word containing 
zero. 

.OVRLA is the only Monitor function that looks at the Overlay Table. 
If the .OVRLA processor finds a match to the .OVRLA argument in the 
Overlay Table, it uses the parameters listed in the table to bring 
it in via a Monitor TRAN. Note that this bypasses the System Loader, 
and does not change the handler load. Thus, the overlay must use only 
those .DAT slots required by the original program, the one listed in 
COMBLK. 

If the .OVRLA processor does not find a match in the Overlay Table, it 
calls in the System Loader, which searches COMBLK for the requested 
program. This type of overlay request does not require that .DAT slot 
assignments be the same. On the other hand, the System Loader refreshes 
all of core except .SCOM, etc. Thus, communication between overlays 
is more difficult. The resident patch area, however, can be used for 
this purpose. 

6.4.2 The Device Table 

The Device Table is built by the System Loader interface whenever PIP 
is being loaded, or when PIP is listed in COMBLK among the overlays 
for a program. It is located just above the register pointed to by 
SC.RMS, and has an entry for each positive .DAT slot plus an additional 
entry indicating the system device code. If a slot has an assigned 
device, the low-order twelve bits of the corresponding entry in the 
Device Table will contain the device's code, in .SIXBT. Bit 2 is set 
when the slot is busy. If no device is assigned to a slot, the corres- 

DOndincr en"fTV in -hhpi Dp^^rir-t^ Tahl<3 will nnn-^-^^in ^.f^yn . 
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6.4.3 The Input/Output Coramunication (IOC) Table 

The System Loader builds the IOC Table and locates it just below the 
first register of the System Loader. It contains an entry for each 
handler in the system, in the order that they appear in SGNBLK. The 
entries themselves contain the handler name in Radix 50. The System 
Loader and the Linking Loader use the handler number supplied by the 
Nonresident Monitor to index down the IOC Table. They use the contents 
of the entry for a .SEEK to the lOS UIC. 

6.4.4 The Device Assignment Table (.DAT) 

The Device Assignment Table makes the association between logical and 
physical devices. The Monitor knows its location by the contents of 
SC.DAT, which points to entry zero in the Table. Specific slots are 
found by indexing on the contents of SC.DAT. The number of negative 
slots is fixed at IS^. The number of positive slots is specified by 

o 

SC.SLT, and may be any positive number less than 100o- It is specified 
with SGEN XVM. 

The Nonresident Monitor places the handler number in the low order 
bits and the unit number in the high order bits. It derives the -hand- 
ler number from SGNBLK. As mentioned above, the System Loader and 
the Linking Loader subsequently use the IOC Table to determine the 
handler name. After either loader has loaded and relocated a handler, 
it places the handler's starting address in the .DAT slot that refer- 
ences that handler. The unit number remains in the high-order three 
bits. Slots with no handler (NON) contain zero. Active .DAT slots 
are designated by COMBLK, for core-image system programs, and by .lODEV 
pseudo-ops for the Linking Loader and EXECUTE. 

6.4.5 The User File Directory Table (.UFD) 

.UFD+0 is offset from .DAT+0 (pointed to by SC.DAT) by the sum of 
the positive and negative .DAT slots. Each .DAT slot has a correspond- 
ing .UFD slot. UIC's in the .UFD are packed in .SIXBT. The address 
of .UFD+0 is stored in SC.UFD. 

6.4.6 The Skip Chain 

Register 1 of Bank contains a jump to the beginning of the Skip Chain, 
The Skip Chain is defined with SGEN XVM, is located in SGNBLK, and is 
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rebuilt every time the System Loader is called in. The SGEN XVM 
Utility Manual describes considerations for constructing the Skip 
Chain. 

6.5 TEMPORARY TABLES BUILT FROM SCRATCH 

6.5.1 File Buffer Transfer Vector Table 

The System Loader allocates space for the buffer pool, and creates the 
File Buffer Transfer Vector Table. SC.BTB points to the first entry 
in the table, and the number of entries is specified by SC.BNM. Each 
entry in the table contains the address of a buffer, or its one's 
complement. Negative address indicate a busy buffer. Since references 
to buffers must be indirect anyway, buffers are allocated without re- 
gard to bank boundaries. 

6.5.2 The Mass Storage Busy Table 

Entries in this table are allocated by the System Loader or the Linking 
Loader. The Mass Storage Busy Table is- pointed to by SC.BTA. SC.BTL 
contains the number of words per entry in the table, and SC.ACT contains 
the current number of entries. Generally speaking, there are as many 
entries in the Busy Table as there are active .DAT slots, although 
the disk handlers are the only ones that currently refer to the Busy 
Table. 

The .INIT command to a disk handler establishes a Busy Table entry. 
The .CLOSE command (or the Rewind .MTAPE command) deletes the corres- 
ponding entry. Table 6-3 illustrates a typical Busy Table Entry. 

The first word of an active entry in the Busy Table contains the .DAT 
slot in bits 9-17. The disk handlers save information about the UFD 
current for this .DAT slot in the Mass Storage Busy Table. They save 
information about the file current to the .DAT slot (if any) in the 
buffer pointed to by word 1 of the Busy Table Entry. More information 
on the disk handlers and file structure is contained in Chapter 7. 

6.6 RESERVED WORD LOCATIONS 

Word locations through 77, are dedicated systems locations. The 

r* on •(- ^ n -I- c; n-f -t-Hoco 1 n/-^3 +- 1 on c a-v-Q /-^qc /-•vt Kor? -in faKT/fi C _ /I 
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Table 6-2 
Overlay Table 



Word # 


Contents 


N,N+1 


.SIXBT name of Overlay or zero if end of table 


N+2 


First block number 




N+3 


First address, minus 1 




N+4 


Size, in two's complement 




N+5 


Fifteen-bit starting address 





Table 6-3 
Mass Storage Busy Table Entry 



Word # 


Contents 


N 


Device Type^ j. Unit Number-__, Write Check,, 


.DATg_^7 


N+1 


Buffer Address, or 0, if none allocated 




N+2 


Three-character UIC 




N+3 


First UFD block for this UIC 




N+4 


UFD Entry size for files in this UFD 





Table 6-4 
Reserved Address Locations 



r -■ ' ' 

ADDRESS 


USE 





Stores the contents of the PC, link, user/exec mode 
status, and bank/page mode status during a program 
interrupt 


1 


JMP to Skip Chain 


2 


Reserved 


3 


.MED, entry to Monitor Error Diagnostic routine 


4 


JMS to error handler 


5 


Reserved 


6 


Reserved 


7 


Stores real time clock count 


10-17 


Autoindex registers 


20 


Stores the contents of the PC, link, user/exec mode 
status, and bank/page mode status on a CAL instruc- 




tion. 


21 


JMS to CAL handler 


22-37 


Seven pairs of word count-current address registers 
for use with 3-cycle I/O device data channels. 


40-77 


Store unique entry instructions for each of 32-j^q auto- 
matic priority interrupt channels. 



6-15 



CHAPTER 7 
FILE STRUCTURES 



7-1 DECTAPE FILE ORGANIZATION 

DECtape can be treated either as a directoried or non-directoried 
device. 

7.1.1 Non-Directoried DECtape 

A DECtape is said to be non-directoried when it is treated as magnetic 
tape by issuing the .MTAPE commands: REWIND or BACKSPACE, followed by 
.READ or .WRITE. No directory of identifying information of any kind 
is recorded on the tape. A block of data (255^^ word maximum), exactly 
as presented by the user program, is transferred into the handler buf- 
fer and recorded at each .WRITE command. A .CLOSE terminates record- 
ing with a software end-of-file record consisting of two words: 001005, 
776773 

Because braking on DECtape allows for tape roll, staggered recording 
of blocks is employed in XVM/DOS to avoid constant turnaround or time- 
consuming back and forth motion of physically sequential block record- 
ing. When recorded as a non-directoried DECtape, block J3. is the 
first block recorded in the forward direction. Thereafter, every fifth 
block is recorded until the end of the tape is reached, at which time 
recording, also staggered, begins in the reverse direction. Five 
passes over the tape are required to record all HOOg blocks. 

7.1.2 Directoried DECtape 

Just as a REWIND or BACKSPACE command declares a DECtape to be non- 
directoried, a .SEEK or .ENTER implies that a DECtape is to be con- 
sidered directoried. A directory listing of any such DECtape is 
available via the (L)ist command in PIP. A fresh directory may be 
recorded via the N or S switch in PIP. 

The directory of all DECtapes occupies all 40|2fg words of block 100g. It 
is divided into two sections: (1) a 40^ word Directory Bit Map and 
(2) a 340O word Directory Entry Section. 
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The Directory Bit Map defines block availability. One bit is allo- 
cated for each DECtape block (llOOp bits = 40o words) . When set to 1, 
the bit indicates that the DECtape block is occupied and may not be 
used to record new information. 

The Directory Entry Section provides for a maximum of 56,^ files on 
a DECtape. Each file on the DECtape has a four-word entry. Each 
entry includes the three-word file name and extension, a pointer to 
the first DECtape block of the file, and a file active or present bit. 
Figure 7-1 illustrates the DECtape directory. 



Word 


t 

37 

40 

A 



377 



Block ^ 

Block Ij2f77 


^r 


Entry J? 


Entry 55^^ 



Directory 
Bit Map 



Directory 

Entry 

Section 



Wd. 
1 
2 
3 



9 


5 6 11 12 


17 


File 


Name 


File Name Extension 


1 


Data Link (First File 


Block) 



Note: Nulls (0) fill 
in short file names. 
A file name extension 
is not absolutely 
necessary. 



Sign Bit: 1 = File Active 
A DIRECTORY ENTRY 

Figure 7-1 
DECtape Directory 



Additional file information is stored in blocks 71 through 77 of every 
director ied DECtape. These are the File Bit Map Blocks. For each file 
in the directory, a 4 0g-word File Bit Map is reserved in block 71 
through 77. The bit maps are contiguous, and the N file uses the 
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N^^ bit map. Each block is divided into eight File Bit Map Blocks. A 
File Bit Map specifies the blocks occupied by that particular file and 
provides a rapid, convenient method to perform DECtape storage re- 
trieval for deleted or replaced files. Note that a file is never de- 
leted until the new one of the same name is completely recorded on 
the .CLOSE of the new file. When a fresh directory is written on 
DECtape, blocks 71 through 100 are always indicated in the Directory 
Bit Map as occupied. Figure 7-2 illustrates DECtape file bit maps. 



Block 71j 
Block 72, 



Block 77, 



Bit 


Map 


for 


File 





Bit 


Map 


for 


File 


7 


Bit 


Map 


for 


File 


8 


Bit 


Map 


for 


File 


1^10 












Bit 


Map 


for 


File 


'h0 


Bit 


Map 


for 


File 


'^10 



Figure 7-2 



DECtape File Bit Map Blocks 



Staggered recording (at least every fifth block) is used on directoried 
DECtapes, where the first block to be recorded is determined by examina- 
tion of the Directory Bit Map for a free block. The first block is 
always recorded in the forward direction; thereafter, free blocks are 
chosen which are at least five beyond the last one recorded. The last 
word of each data block recorded contains a data link or pointer to 
the next block in the file. When turnaround is necessary, recording 
proceeds in the same manner in the opposite direction. When reading, 
turnaround is determined by examining the data link. If reading has 
been in the forward direction, and the data link is smaller than the 
last block read, turnaround is required. If reverse, a block number 
greater than the last block read implies turnaround. 

A software end-of-file record (001005, 776773) terminates every file. 
The data link of the final block is 777777. 
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Data organization for each I/O medium is a function of the data modes. 
On directoried DECtape there are two forms in which data is recorded: 
(1) packed lines - lOPS ASCII, lOPS Binary, Image Alphanumeric, and 
Image Binary, and (2) dump mode data - Dump Mode. 

In lOPS or Image Modes, each line (including header) is packed into 
the DECtape buffer. In lOPS Binary, a 2's complement checksum is com- 
puted and stored in the second word of the header. When a .WRITE 
which will exceed the remaining buffer capacity is encountered, the 
buffer is output, after which the new record is placed in the empty 
buffer. No record may exceed 254,- words, including header, because 
of the data link and even word requirement of the header word pair 
count. An end-of-file is recorded on a .CLOSE. It is packed in the same 
manner as any other line. 



In Dump Mode, the word count is always taken from the I/O macro. If 
a word count is specified which is greater than 255, ^ (note that space 
for the data link must be allowed for again) , the DECtape handler will 
transfer 255 ^ word increments into the DECtape buffer and from there 
to DECtape. If some niimber of words less than 255, p. remain as the 
final element of the Dump Mode .WRITE, they will be stored in the DEC- 
tape buffer, which will then be filled on the next .WRITE, or with an 
EOF if the next command is .CLOSE. DECtape storage is thus optimized 
in Dump Mode since data is stored back-to-back. See Appendix A. 

7.2 MAGNETIC TAPE 

DOS provides for industry-compatible magnetic tape as either a di- 
rectoried or non-directoried medium. The magnetic tape handlers com- 
municate with a single TC-59D Tape Control Unit (TCU) . Up to eight 
magnetic tape transports may be associated with one TCU; these may 
include any combination of transports TU-lOA or B and TU-20A or B. 

There are a number of major differences between magnetic tape and DEC- 
tape or Disk; these differences affect the operation of the device 
handlers. Magnetic tape is well suited for handling data records of 
variable length. Such records, however, must be treated in serial 
fashion. The physical position of any record may be defined only in 
relation to the preceding record. Three techniques available in I/O 
operations to block-addressable devices are not honored by the magnetic 
tape handlers: 
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a. 



b. 



c. 



The user cannot specify physical block numbers for 
transfer. In processing I/O requests that have block 
niimbers in their argument lists (i.e., .TRAN) the 
handler ignores the block-number specification. 

The only area open for output transfers in the direc- 
toried environment is that following the logical end 
of tape. 

Only a single file may be open for transfers (either 
input or output) at any time on a single physical unit, 



7.2.1 Non-directoried Data Recording (MTF) 

MTF is intended to satisfy the requirements of the FORTRAN programmer 
while still providing the assembly language programmer maximiim freedom 
on the design of his tape format. MTF writes out a record to the tape 
each time the main program issues a .WRITE. The length of the record 
is always two times the word pair count in the header word pair. FIOPS 
records are always as long as the buffer size returned on a .INIT (up 
to 256,^ words). MTF returns a standard buffer size of 377g/ after a 
.INIT. The FORTRAN user may dynamically change this size, however, 
via the following instructions 

Example: 



(FORTRAN STATEMENTS) 



CALL SETMTB (IBFSIZ) 



(MACRO STATEMENTS) 

.TITLE SETMTB 

.GLOBL .DA, MTBSIZ, SETMTB 



SETMTB 









JMS* 


.DA 




JMP 


START 


BUFSIZ 







START 


LAC* 


BUFSIZ 




DAC* 


MTBSIZ 




JMP* 


SETMTB 




.END 





(any buffer size) 



7.2.2 



Directoried Data Recording (MTA. , MTC.) 



The programmer can make the fullest possible use of those features 
peculiar to magnetic tape by using MTF. On the other hand, MTF does 
not offer the powerful file-manipulation facilities available in the 
system. Directoried I/O allows device independence, and extensive 
use of the storage medium with a minimum of effort. 



MTA 



and MTC. do not support non-directoried data recording. 
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Every block recorded by MTA. (with the exception of end-of-file markers, 
which are hardware-recorded) includes a two-word Block Control Pair 
and not more than 255, ^ words of data. The data will contain the 
records from one or more .WRITE 's. 

The Block Control Pair serves three functions: it specifies the char- 
acter of the block (label, data, etc.), provides a word count for the 
block, and gives an 18-bit block checksum. The Block Control Pair has 
the following format; 

Word 1 ; 

Bits through 5: Block Identifier (BI). This 6-bit byte 
specifies the block type. Values of BI may range from 
to 77 g. Current legal values of BI, for all user files, 
are as follows: 



BI Value 

00 
10 
20 



Block Type Specified 

User-File Header Label 
User-File Trailer Label 
User-File Data Block 



Bits 6 through 17: Block Word Count (BWC) . This 12-bit 

byte holds the 2's complement of the total number of words 

in the block (including the Block Control Pair) . Legal 

values of BWC range from -3 to -401^. 

o 

Word 2: 



Bits through 16: Block Checksum. The Block Checksum is 
the full-word, unsigned, 2's complement sum of all the 
data words in the block and word 1 of the Block Control 
Pair. 



BCP WORD I 
BCP WORD 2 



N-2 DATA J 
WORDS ^ 



5 6 

I I I I I 



BLOCK ID 
I I I I I 



I I I I I I r 



I I I I I I I I I I I 



-BLOCK CHECKSUM- 



I I I I I I I ' I I I I I I I I I 



N TOTAL WORDS 
IN BLOCK 



Figure 7-3 



Block Format, File-Structured Mode 
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One of the main file functions of MTA. and MTC. is that of identifying 
and locating referenced files. This is carried out by two means: 
first, names of files recorded are stored in a file directory at the" 
beginning of the tape; and second, file names are contained in the 
file's header and trailer labels. 

7.2.2.1 Magnetic Tape File Directory 

The directory, a single-block file (and the only unlabeled file on any 
file-structured tape) , consists of the first recorded data block on 
the tape. It is a 257, p. v7ord block v/ith the following characteristics: 

a. Block Control Pair (words 1 and 2) 

Word 1 

Block Identifier = 74^ = File Directory Data Block 

o 

Block Word Count = -401g = 7377g. 

Word 2: 

Block Checksum: As described above. 

b. Active File Count (Word 3, Bits 9 through 17) 9-bit one's 
complement count of the active file names present in the 
File Name Entry Section (described below) . 

c. Total File Count (Word 3, Bits through 8) 9-bit one's 
complement count of all files recorded on the tape, in- 
cluding both active and inactive files, but not the file 
directory block. 

d. File Accessibility Map. (Words 4 through 17) : The File 
Accessibility Map is an array of 252t_q contiguous bits 
beginning at bit of word 4 and ending as bit 17 of 
word 17. Each of the bits in the Accessibility Map re- 
fers to a single file recorded on tape. The bits are 
assigned relative to the zero^h file recorded; that is, 
bit of word 4 refers to the first file recorded; bit 
1, word 4, to the second file recorded; bit 0, word 6, 
to the 37iq"^^ file recorded; and so on, for a possible 
total of 252-,^ files physically present. 

A file is only accessible for reading if its bit in the 
Accessibility Map is set to one. A file is made inac- 
cessible for reading (corresponding bit =0) by a .DLETE 
of the file, by a .CLOSE (output) of another file of the 
same name, or by a .CLEAR. A file is made accessible for 
reading (corresponding bit =1) by a .CLOSE (output) of 
that file. Operations other than those specified above 
have no effect on the File Accessibility Map. 
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BIT POSIT ION 
6 9 12 




F I LE 

ACCESSI BILITY 

MAP 



FILE 

NAME 

ENTRY 

SECTION 



WORD 1 6 
WORD 1 7 
WORD 18 



WORD 2 1 



WORD 24 



WORD 257 
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BLOCK 


CHECKSUM 
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01011 


CONTENTS 
UNSPEC IFIED 
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E 




# 


2 




E 
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T 
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# 


4 




E 




X 


T 




F 




I 


L 




E 




# 


5 




E 




X 


T 




M 


CONTENTS 
UNSPECI FlED 


1 


/v 



BEGIN NING 
OF TAPE 



FILE 
D I RECTORY 



FILE #1 
(INACTIVE) 



FILE #2 
(ACTIVE) 



FILE #3 
(INACTIVE) 



FILE #4 
(ACTIVE) 



FILE #5 
(ACTIVE) 



END OF TAPE 



Figure 7-4a. Format of the 
File Directory Data Block, 
showing relationship of active 
and inactive files to file name 
entries and to Accessibility Map 



Figure 7-4b. Format of file- 
structured tape, showing 
directory block and data 
files . 



Figure 7-4 
Magtape File Structure 
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e. File Name Entry Section (Words 18 through 257): The File 
Name Entry Section, beginning at word 18 of the direc- 
tory block, includes successive 3-word file name entries 
for a possible maximimi of 80 entries. Each accessible 
file on the tape> has an entry in this section. Entries 
consist of the current name and extension of the refer- 
enced file in .SIXBT (left-adjusted and, if necessary, 
zero-filled) . 

The position of a file name entry relative to the begin- 
ning of the section reflects the position of its accessi- 
bility bit in the map. That bit, in turn, defines the 
position of the referenced file on tape with respect to 
other (active or inactive) files physically present. Only 
active file names appear in the entry section, and access- 
ibility bits for all inactive files on the tape are always 
set to zero; accessibility bits for all active files are 
set to one. 

To locate a file on the tape having a name that occupies 
the second entry group in the File Name Entry Section, 
the handler must (a) scan the Accessibility Map for the 
second appearance of a 1-bit, then (b) determine that bit's 
location relative to the start of the map. That location 
specifies the position of the referenced file relative to 
the beginning of the tape. The interaction of the File 
Name Entry Section and the Accessibility Map are shown 
in Figure 7-4. 



7.2.2.2 user-File Labels 



Associated with each. file on tape is one label, the header label. 

precedes the first data block of the file 

in length. Label format is shown in Figure 7-5. 



It 



Each label is 27, ^ words 



WORD 1 


00 


7745 




WORD 2 


CHECKSUM 


J 


WORD 3 


777 XXX 


FILE NAME 


WORD 4 


000000 




WORD 5 




J 






. ___- 


> RESERVED 






WORD 26,0 






WORD 27,0 







Figure 7-5 



User File Header Label Format 
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7.2.2.3 File-Names in Labels 

The handler will supply the contents of the file-name fields (Word 3) 
in labels. These are used only for control purposes during the execu- 
tion of .SEEK's. The name consists simply of the two's complement of 
the position of the recorded file's bit in the Accessibility Map; the 
"name" of the first file on tape is 777777, that of the third file is 
777775, and so on. A unique name is thus provided for each file physi- 
cally present on the tape. Since there may be a maximum of 252^^ files 
present, legal file-name values lie in the range 777777 to 777404. 

7.2.3 Continuous Operation 

Under certain circumstances, it is possible to perform successive I/O 
transfers without incurring the shut-down delay that normally takes 
place between blocks. The handler stacks transfer requests, and thus 
ensures continued tape motion, under the following conditions: 

a. The I/O request must be received by the CAL handler be- 
fore a previously-initiated I/O transfer has been com- 
pleted. 

b. The unit number must be identical, to that of the pre- 
viously initiated I/O transfer. 

c. The I/O request must be one of those listed below to 
ensure successful completion. The handler in process- 
ing requests in continuous mode depends on receiving 
control at the CAL level in order to respond to I/O 
errors. The functions for which continuous operation 
is attempted include only the following: 

1. .MTAPE 3. .WRITE 

2. .READ 4. .TRAN 

d. With MTA, more than one logical record may be in a physical 
block, so tape motion may stop if fewer successive .READ's 
or . WRITE 's "are issued than there are records in a block. 

e. The previously-requested transfer must be completed v-ith- 
out error. In general, successive error-free READ's 

(WRITE' s) to the same transport will achieve non-stop 
operation. The following examples illustrate this prin- 
ciple. 

Example 1: Successful Continued Operation 

SLOT = 1 

INPUT = 

BLOKNO = 

READl .TRAN SLOT, INPUT, BLOCKNO, BUFFI, 257 

READ2 .TRAN SLOT, INPUT, BLOCKNO, BUFF 2 , 257 

RETURN JMP READl 



The program segment in Example 1 will most probably keep the refer- 
enced transport (.DAT slot 1) up to speed. The probability decreases 
as more time elapses between READl and READ2 , and between READ2 and 
RETURN. Each .TRAN request causes an implicit .WAIT until its opera- 
tion is completed. 

Example 2: Unsuccessful Continued Operation 

SLOT = 1 

INPUT = 

BLOKNO = 

READ .TRAN SLOT, INPUT, BLOKNO, BUFF, 257 

STOP .WAIT SLOT 

RETURN JMP READ 

The program segment in Example 2 will not keep the tape moving because 
the .WAIT at location STOP prevents control from returning to location 
READ until the transfer first initiated at READ has been completed. 

Example 3: Unsuccessful Continued Operation 

SLOTl = 1 

SL0T2 = 2 

INPUT = 

BLOKNO = 

READl .TRAN SLOTl, INPUT, BLOKNO, BUFFI, 25 7 

READ2 .TRAN SL0T2 , INPUT, BLOKNO, BUFF 2 , 257 

RETURN JMP READl 

This program segment will not provide non-stop operation because of 
the differing unit specification at READl and READ 2 . 

7.2.4 Storage Retrieval on File-Structured Magnetic Tape 

The use of a file accessibility map as well as block identifiers in 
Magtape file directories makes it almost impossible to retrieve the 
area of a deleted file from a magnetic tape. The execution of the 
deletion command (i.e., .DLETE) removes the name of the object file 
from the file directory, and clears the corresponding bit in the File 
Accessibility Map. 

The only circumstance under which a file area may be easily retrieved 
is when the deleted file is also the last file physically on the tape. 
Under these conditions, the handler can retrieve the area occupied by 
the deleted file when the next .ENTER - .WRITE - .CLOSE sequence is 
executed. Users may also copy the active files to another device, re- 
new the directory, and recopy the files. 
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7.3 DISK FILE STRUCTURE 
7.3.1 Introduction 

The XVM/DOS disk file structure is in some ways analogous to DECtape 
file structure. Ordinarily, each disk user has a directory which 
points to named files, just as each DECtape has a directory. The DEC- 
tape has only one directory, but the disk has as many directories as 
users have cared to establish. A single user's disk directory might 
correspond to a single DECtape directory. A single disk file's size 
is also limited only by the available space, as is true with DECtape. 
Although DECtape directories may reference a maximum of 56 ^^ files, the 
number of files associated with any one directory on the disk is limited 
only by the available disk space. 

The DECtape directory is in a known location — at block 100. Since 
the disk may have a variable number of directories, the Monitor must 
know how to find each user's directory. It therefore maintains a 
Master File Directory (MFD) at a known location^ and the Master File 
Directory points to each User File Directory (UFD) . XVM/DOS allows 
only those users who know the Master Identification Code to have ac- 
cess to any protected UFD's within the MFD. Figure 7-6 illustrates 
the MFD. Appendix B is a flowchart of the Disk "A" Handlers. 

7.3.2 User Identification Codes (UIC) 

The Monitor finds User File Directories by seeking associated User 
Identification Codes (UIC's), which are all listed in the Master File 
Directory. The UIC is a three-character code that is necessary for 
all non-.TRAN I/O to the disk. .TRAN macros use no directory refer- 
ences. A programmer may operate under as many UIC's as he wishes, pro- 
vided all are unique and none is reserved^ . He may establish a new 
User File Directory by (1) logging in his new UIC to the Monitor via 
the LOGIN command, (2) calling PIP, and (3) issuing an Nj_,DK command. 
This establishes a new User File Directory, or refreshes (wipes clean) 
an old directory under that UIC. (.ENTER will also create a new MFD 
entry and/or a UFD, if none exists.) Figure 7-7, User File Directory, 
illustrates the organization of a UFD. 



On the RF and RK disk, the first block of the MFD is 1777 octal. 
^On the RP disk, the first block of the MFD is 47040 octal. 
The following are reserved UIC's: @@@, ???, PAG, BNK, SYS, lOS, CTP. 
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Word # 


Contents 


Description 


ja 


777777 


Dummy UIC used by system. 


1 


nnnnnn 


Bad Allocation Table's first block number, 
or 777777, if there is none. 


2 


nnnnnn 


SYSBLK's first block number, or -1, if 
there is none. 


3 


4- _+blknum 
j3-2 

• 


MFD entry size in bits j?-2 , plus the block 


• 


number of the first submap 


4N 


.SIXBT 


UIC for this UFD 


4N+1 


nnnnnn 


Block number for the first block of this 
UFD or 777777, if no UFD exists (as after 
PIP'S Ni_iDK^) 


4N+2 


P^+M 


Protection code in bit 0, plus the UFD 




entry size for each file 


4N+3 


spare 


Unused at this writing 


375-^ 


nnnnnn 


Spooler disk area size 


nnnnnn 


Spooler disk area starting block 


376 


nnnnnn 


Pointer to previous MFD block, or 777777 
if none. 


377 


nnnnnn 


Pointer to next MFD block, or 777777 if 
none. 



Figure 7-6 
Master File Directory 



Word # 


Contents 


Description 


8N 


.SIXBT 


Name of this file 


8N+1 


.SIXBT 


and its 


8N+2 


.SIXBT 


extension 


8N+3 


Trt+blknum 
i3 


Truncation code in bit 0, plus the number 




of the first block of the file 


8N+4 


nnnnnn 


Number of blocks in this file 


8N+5 


ribptr 


Pointer to the first block of the Retrieval 
Information Block 


8N+6 


Prt T+ribwrd 
jd-1 


Protection code in bits 0-1, plus the 




first word in ribptr used by the RIB — if 






the last block of the file has room for 






the RIB, the handlers will put it there. 






and load word 8N+6 accordingly. 


8N+7 


crdate 


Date of file's creation -mmddyy (yy modulo 70) 


376 


nnnnnn 


Pointer to previous block, or 777777 if none 


377 


nnnnnn 


Pointer to next UFD block, or 777777 if none 





Figure 7-7 
User File Directory 



Bits 0-1 of word 374 are concatenated with bits 0-1 of word 375 to 
produce a 4-bit checksum for the 16-bit fields of words 374,375. Check- 
sum = word 374 (2-17) + word 375 (2-17) + 1 (modulo 16^^-) . 
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7.3.3 Organization of Specific Files on Disk 

The Disk Handlers write out files in almost the same way that a DEC- 
tape handler does. Disk file blocks, however, have a forward and 
backward link. (Non-dump records are therefore limited to lengths 
of 254^Q words.) Further, upon receipt of a .CLOSE I/O macro, the disk 
handlers fill out a Retrieval Information Block (RIB) . The RIB per- 
forms the same functions as the file bitmap on DECtape, and also as- 
sociates the logical sequence of blocks in the file with the physical 
locations of the blocks on the disk. The disk handler uses the RIB to 
implement .RTRAN commands and to delete files. Figure 7-8, The Retrieval 
Information Block, illustrates a RIB. 

After a user has created a disk file he can access logical records 
sequentially via .READ commands, just as with DECtape files. He can 
also access physical blocks of that file by referencing relative block 
numbers in the .RTRAN command. (The .RTRAN commands require the file 
be opened with the .RAND command.) 

7.3.4 Buffers 

The handlers break buffers from the pool into three parts: (1) File 
Information (about 4^3- words)*, (2) the Block List — addresses of 
pre-allocated blocks (between 4 and 253,0 addresses, inclusive), and 
(3) data buffer (256^j^ words) . Figure 7-9, Disk Buffer, illustrates 
the breakdown of disk buffers. 

7.3.4.1 Commands That Obtain And/or Return Buffers 

The following commands obtain buffers from the pool, and return them 
imjnediatelv after execution: 

. DLETE 
.RENAM 
. CLEAR 

The following commands obtain a buffer from the pool and do not return 
it until a subsequent .CLOSE is performed: 

.FSTAT 
.ENTER 
.SEEK 
.RAND 



*This number is determined by assembly parameters. 
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Word # 


Contents 


Description 


0* 




nnnnnn 


Total number of blocks described by this 
physical block. 


1 
2 
3 




nnnnnn 
nnnnnn 
nnnnnn 


First data block pointer. 
Second data block pointer. 
Third data block pointer. 


376 




nnnnnn 


Pointer to previous RIB block or -1 if no 
previous RIB block. 


377 




nnnnnn 


Pointer to next RIB block or -1 if no 
next RIB block. 


* Zero^^ word of the RIB may not be zero ^ word of physical block. 
This occurs whenever the entire RIB will fit in the last data 
block of the file. 



Figure 7-8 
Retrieval Information Block 



4 0o Words* 


< 


More than 3 and 
less than 377o 
words 

1 


i 


400o Words 
o 


i 



File Information becomes 
'Current Set' when file active 
(see 7. 3.4.2) . 



Addresses of Preallocated 
Blocks (Block List or Temp 
List or TLIST) 



Data Buffer 



*This is not a fixed number. It is 
different for RP, RK and RF. 

Figure 7-9 
Disk Buffer 
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The following commands return a buffer to the pool, if any was allo- 
cated. 

.INIT 

. CLOSE 

.MTAPE (rewind) 

7.3.4.2 The Current Set 

The handlers retain information about the last file and .DAT slot 
processed in an internal storage area. This area is called the 
"Current Set", and is swapped back to the file's buffer whenever a 
command to a different file is used. Thus, 

.WRITE to .DAT slot A 
.WRITE to .DAT slot B 

will swap the Current Set, but... 

.WRITE to .DAT slot A 
.TRAN to .DAT slot A 
.WRITE to .DAT slot A 

will not swap the Current Set. 

7.3.5 Pre-allocation 

The handlers pre-allocate blocks on the disk upon all .ENTER commands, 
and whenever sufficient .WRITE commands have been issued to use up the 

pre-allocated blocks. The number of pre-allocated blocks will be the 
minimum of the number of free blocks on the device and the number of 
address slots available in the Temp List (block list) . 

When the handlers pre-allocate blocks, they fill out the bit maps, and 
immediately fill out the RIB and write it out in one of the pre-allocated 
blocks . 

Upon a .CLOSE command, the handlers give back unused blocks, and re- 
write the RIB. 



The number of blocks in the Block List depends on the size of the 
buffer, which is determined at system generation by setting the buffer 
size. The larger the Block List, the faster will be output. Smaller 
Block Lists may give more efficient allocation of core and disk space. 
Smaller buffers save core. Further, the number of pre-allocated blocks 
may affect concurrently opened files on a disk that is tight for space. 
Thus, if the Block List is sixty entries long, and there are forty 
blocks left on the disk, a .ENTER to .DAT slot will pre-allocate all 
forty, leaving none for any subsequent .ENTER' s to different .DAT 
slots. 

lOPS 70 will occur when there are less than four free blocks on the 
disk when a handler tries to pre-allocate blocks. 



7.3.6 Storage Allocation Tables (SAT's) ^ 

The disk handlers use a Storage Allocation Table, in order to distin- 
guish between allocated and free blocks. If more than one physical 
block is required, the individual blocks are called Submaps. 

Unlike DECtape , the Storage Allocation Table is never held in core. 
When the handlers wish to preallocate some blocks, they read in the 
required Submap, and write out the updated one. 

Storage Allocation blocks use the following format: 

WORD Total blocks on the disk 

WORD 1 Number of blocks described 

by this Submap 
WORD 2 Number of blocks occupied 

in this Submap 
WORD 3 First word of the bit map 

(eighteen blocks per word) 



WORD 376 Pointer to previous Submap 

(or 777777) 
WORD 377 Pointer to next Submap 

(or 777777) 

The bit maps refer to blocks in numerical order. Thus, bit of word 
three of a Submap will refer to block N, bit 1 will refer to block N+1, 
and so on. The block is free if the corresponding bit equals 0. Start- 
ing and ending block numbers for all Submaps are retained in the hand- 
lers. Bit of word three in the first submap, refers to block zero. 



^The first SAT block is located at 1776 „ for the RF and RK system and 
764^ for the RP system » 
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7.3.7 Bad Allocation Tables (BAT's) 

Occasionally, a particular block on the disk will not record data cor- 
rectly. In such instances, the handlers should be prevented from using 
the bad blocks. Accordingly, PIP maintains a Bad Allocation Table. 
Whenever a user updates that table, PIP will set the appropriate bit 
in the Storage Allocation Table. The block is thus made unavailable. 
Refer to the PIP XVM Utility Manual for more information. 
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CHAPTER 8 
WRITING NEW I/O DEVICE HANDLERS 

This chapter contains information essential for writing new I/O device 
handlers to work in DOS. 

8.1 I/O DEVICE HANDLERS, AN INTRODUCTION 

All communications between user programs and I/O device handlers are 
made via CAL instructions followed by an argument list. The CAL 
Handler in the Monitor performs preliminary setups, checks the CAL 
calling sequence, and transfers control via a JMP* instruction to the 
entry point of the device handler. When the control transfer occurs 
(see Figures 8-1 and 8-2) , the AC contains the address of the CAL in 
bits 3 through 17 and bits 0, 1, and 2 indicate the status of the Link, 
Bank/Page mode, and Memory Protect, respectively, at the time of the 
CAL. Note that the contents of the AC at the time of the CAL is not 
preserved when control is returned to the user. 

On machines that have API, the execution of a CAL instruction automati- 
cally raises the priority to the highest software level (level 4) . 
Control passes to the handler while it is still at level 4. Device 
handlers must remain at level 4 until control is returned to the user. 

A debreak and restore (DBR) instruction should be executed just prior 
to the JMP* which returns control to the user, allowing debreak from 
level 4 and restoring the conditions of the Link, Bank/Page mode, and 
Memory Protect. Any lOT's issued at the CAL level (level 4 if API 
present, mainstream if no API) should be executed immediately before the 

DBR 
JMP* 
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Figure 8-1 
CAL Eiitr" to Dsvicc K'^ndl'^ir 



For non-unibus devices both these branches would be replaced by a single initiate 

function routine. 
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Figure 8-2 
PI and API Entries to Device Handlers 
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exit sequence in order to ensure that the exit takes place before the 
interrupt from the issued lOT occurs. 

CAL's may be executed within an I/O handler, but not while processing 
an interrupt. 

8.1.1 Setting Up the Skip Chain and API (Hardware) Channel Registers 

When the Monitor is loaded, the Program Interrupt (PI) Skip Chain and 
the Automatic Priority Interrupt (API) channels are set up to handle 
the TTY keyboard and printer and clock interrupts only. The Skip 
Chain contains the other skip lOT instructions, but indirect jumps to 
an error routine result if a skip occurs. 



All unused API channels, memory protect, memory parity, and powerfail, 
also transfer control to the error address. 

When a device handler is called for the first time in a core load, it 
must call a Monitor routine (.SETUP) to set up its skip(s) in the Skip 
Chain, or its API channel, prior to performing any I/O functions. 

The calling sequence is as follows: 

CAL N /N = API channel register 40 through 77. 

/O if device not connected to API. 
16 /.SETUP function code. 

SKP lOT /Skip lOT for this device. 
DEVINT /Address of interrupt handler, 

(normal return) 

8.1.2 Handling the Interrupt 

DEVINT exists in the device handler in the following format to allow 
for either API or PI interrupts. The following is for UNIBUS devices 
only: 
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ONLYl LAC 
DAC 
DAC 
DAC 
JMP 

DEVPIC DAC 
LAC* 
DAC 

JMP 
DEVINT JMP 
DAC 
LAC 
DAC 
IGNRPI JMP 



COMMON CAPI- 
DEVION ION 



(NOP 
DEVION 
DEVIOF 
IGNRPI 
COMMON 
DEVAC 

DEVOUT 

COMMON 

DEVPIC 

DEVAC 

DEVINT 

DEVOUT 

ONLYl 



/LEAVE PI ALONE. WHEN API IS RUNNING 

/THESE REGISTERS 

/ARE AVAILABLE 

/THIS IS ONCE ONLY CODE 

/SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 
/MEMORY PROTECT 

/PI ENTRY 

/API ENTRY; SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 

/API IS OPERATING, SO LEAVE PI ALONE. 

/PI INTERRUPTS ARE NOT POSSIBLE, BE- 

/CAUSE .SETUP EFFECTIVELY NOP ' S PI 

/SKIPS. 

/CLEAR API LEVEL *"-' DONE FLAG. 

/PI ALLOWS INTERRUPTS; API DOES A NOP - 



DEVIOF lOF 

LAC 
SIOA 
JMP 
LIOR 

• 

/DISMISS ROUTINE 



/API DOES NOP; PI TURNS 10 OFF TO ENSURE 
/NON-REENTRANCE AFTER ISSUING lOT ' S . 

(TCB /GET ADDRESS OF TCB IN AC 
/PREVIOUS TCB ACCEPTED? 

.-1 /NO 

/YES. LOAD REGISTER IN INTERRUPT LINK 
/THIS CAUSES A BR7 (HIGHER LEVEL) 
/INTERRUPT ON THE PDP-11. 



DVSWCH 



LAC 
ION 
DBR 
JMP* 



DEVAC 



DEVOUT 



/RESTORE AC. 

/ION OR NOP. 

/DEBREAK AND RESTORE CONDITIONS 

/OF LINK, ADDRESSING MODE AND MEMORY 

/PROTECT . 



If the Index, Autoincrement, or EAE registers are used by the I/O de- 
vice handler, it is necessary to save and restore them. 
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The following is for non-UNIBUS devices: 



ONLYl LAC (NOP 

DAC DEVION 

DAC DEVIOF 

DAC IGNRPI 

JMP COMMON 

DEVPIC DAC DEVAC 

LAC* {0 

DAC DEVOUT 

JMP COMMON 

DEVINT JMP DEVPIC 

DAC DEVAC 

LAC DEVINT 

DAC DEVOUT 

IGNRPI JMP ONLYl 



COMMON DEVCF 
DEVION ION 



/LEAVE PI ALONE. WHEN API IS RUNNING 

/THESE REGISTERS 

/ARE AVAILABLE 

/THIS IS ONCE ONLY CODE 

/SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 
/MEMORY PROTECT 

/PI ENTRY 

/API ENTRY; SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 

/API IS OPERATING, SO LEAVE PI ALONE. 

/PI INTERRUPTS ARE NOT POSSIBLE, BE- 

/CAUSE .SETUP EFFECTIVELY NOP'S PI 

/SKIPS. 

/CLEAR DEVICE DONE FLAG. 

/PI ALLOWS INTERRUPTS; API DOES A NOP, 



DEVIOF lOF 



DEVIOT 



/DISMISS ROUTINE 



/API DOES NOP; PI TURNS 10 OFF TO ENSURE 
/NON-REENTRANCE AFTER ISSUING lOT'S. 



DVSWCH 



LAC 
ION 
DBR 
JMP* 



DEVAC 



DEVOUT 



/RESTORE AC. 

/ION OR NOP. 

/DEBREAK AND RESTORE CONDITIONS 

/OF LINK, ADDRESSING MODE AND MEMORY 

/PROTECT . 



If the Index, Autoincrement, or EAE registers are used by the I/O de- 
vice handler, it is necessary to save and restore them. 

.SETUP must contain information for both API and PI. The XVM/DOS 
Monitor will set up the skip chain and/or API channels appropriately, 
The SGEN XVM Utility Manual gives the method for incorporating new 
handlers and associated Skip Chain entries into the Monitor. 
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8.2 WRITING SPECIiyL I/O DEVICE HANDLERS 

This chapter contains information prepared specifically to aid those 
users who plan to write their own special I/O device handlers for DOS. 

DOS is designed to enable users to incorporate their own device hand- 
lers. Precautions should be taken when writing the handler however, 
to ensure compatibility with the Monitor. 

Here is a summary of handler operation. The handler is entered via a 
JMP* from the Monitor as a result of a CAL instruction. The contents 
of the AC contain the address of the CAL in bits 3 through 17. Bit 
contains the Link, bit 1 contains the Bank/Page Mode status, and bit 2 
contains the Memory Protect status. The previous contents of the AC 
are lost. 

In order to show the steps required in writing an I/O device handler, 
a complete handler (Example B) was developed with the aid of a skeleton 
handler (Example A) . In addition, Appendices A and B are flowcharts 
of DTA and the A version of the disk handlers. Example A is referenced 
by part niombers to illustrate the development of Example B, a finished 
Analog-to-Digital Converter (ADC) I/O Handler. The ADC handler shown 
in Example B was written for the Type AFjSflB Analog to Digital Converter, 
This handler is used to read data from the ADC and store it in the 
user's I/O buffer. 

The reader, while looking at the skeleton of a specialized handler 
as shown in Example A, should make the following decisions about his 
own handler. (The decisions made in this case are in reference to 
developing the ADC handler) : 

a. Services that are required of the handler (flags, 
receiving or sending of data, etc.) - By looking 
at the ADC lOT's shown in the Reference Manual, it 
can be seen that there are three lOT instructions 
to be implemented. These instructions are: Skip 
if Converter Flag Set, Select and Convert, and Read 
Converter Buffer. 
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The only service the ADC handler performs is that of 
receiving data and storing it in user specified areas. 
This handler will have a standard 256-word buffer. 

b. Data Modes used (for example, lOPS ASCII, etc.) - 
Since there is only one format of input from the 
Type AFOIB ADC, mode specification is unnecessary in 
Example C. 

c. Which I/O macros are needed for the handler's specific 
use; that is, . INIT , .CLOSE, .READ, etc. For an ADC, 
the user would be concerned with four of the macros. 

(1) .INIT would be used to set up the associ- 
ated API channel register or the interrupt 
skip lOT sequence in the Program Interrupt 
Skip Chain. This is done by a CAL (N) as 
shown in Part III of Example A, where (N) 
is the channel address. 



(2) .READ is used to transfer data from the ADC. 
When the .READ macro is issued, the ADC 
handler will initiate reading of the speci- 
fied number of data words and then return 
control to the user. The analog input data 
received is in its raw form. It is up to 
the programmer to convert the data to a 
usable format. 

(3) .WAIT detects the availability of the user's 
buffer area and ensures that the I/O trans- 
fer is completed. It would be used to ensure 
a complete transfer before processing the re- 
quested data. 

(4) .WAITR detects the availability of the user's 
buffer area as in (3) above. If the buffer 
is not available, control is returned to a 
user specified address, which allows other 
processing to continue. 

d. Implementation of the API or PIC interrupt service routine 
Example A shows an API or PIC interrupt service routine 
that handles interrupts, processes the data and initi- 
ates new data requests to fully satisfy the .READ macro 
request. Notfe that the routines in Example A will oper- 
ate with or without API. Example B uses the routines 
exactly as they are shown in Example A. 

During the actual writing of Example B, consideration was 
given to the implementation of the I/O macros in the new 
handler in one of the following ways : 

(1) Execute the function in a manner appropriate 

to the given device as discussed in(c). .INIT, 
.READ, .WAIT, and .WAITR were implemented into 
the ADC handler (Example B) under the subroutine 
names ADINIT, ADREAD, ADWAIT (.WAIT and .WAITR). 

Wait for completion of ^-irevious I/O. (Example B 
shows the setting of the ADUND switch in the ADREAD 
subroutine to indicate I/O underway.) 



(2) Ignore the function if meaningless to the device. 
See Example B (.FSTAT results in JMP ADIGN2) in 
the dispatch table DSPCH. For ignored macros, 
the return address must be incremented in some 
cases, depending upon the number of arguments 
following the CAL. 

(3) Issue an error message in the case where it is 
not possible to perform the I/O function - (An 
example would be trying to execute a .ENTER on 
the paper tape reader.) In Example B, the handler 
jumps to DVERR6 which returns to the Monitor with 
a standard error code in the AC. 



e. Special considerations for UNIBUS device handlers 

When new handlers are written for devices on the- UNIBUS 
in a UC15 system (RK based or RF/RP based UC15 option) 
the following has to be considered. 

Since communication between the device handler on the 
XVM and the driver task running under PIREX on the 
PDP-11 is through Task Control Blocks (TCB) , space in 
the Common Memory (memory that can be addressed by the 
XVM and the PDP-11) must be provided. The system as 
supplied by DEC has space reserved in the Resident 
Monitor for 3 user defined devices/programs/tasks, 
(refer to Section 2.9 for more information). This TCB 
must be properly setup (refer to the XVM UNICHANNEL 
Software Manual for more information) before the hand- 
ler calls PIREX to initiate the operation. 

Driver tasks (TTT) running under PIREX report errors 
by setting the appropriate code (XX) in the device 
error status table in PIREX (refer to XVM UNICHANNEL 
Software Manual , for more information) . The XVM/DOS 
poller prints out this error message, which appears 
as follows: 

lOPSUC TTT XX 

Users have to decipher this message. An example of this is, 

lOPSUC LPU 4 

which reports that the LPll/LSll line printer is not 
ready. There is no error message type out from the 
handler. This method of error handling is incorporated 
to permit error report during operation of these 
devices/tasks etc., under PIREX when their corresponding 
handlers are not present in core on the XVM (e.g., 
during Spooling) . 



^Each task running under PIREX has a 3 character code assigned to 
it which is present in the PIREX error table at assembly time. 
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After the handler has been written and assembled, the Monitor must 
then be modified to recognize the new handler. This is accomplished 
by the use of SGEN XVM described in the SGEN XVM Utility Manual. 

When the system generation is complete, PIP XVM (refer to PIP XVM 
Utility Manual) must be used to add the new handler to the lOS UFD. 
At this time, the user is ready to use his specialized device handler 
in the XVM/DOS system. 



2.1 Discussion of Example A by Parts 

Part 1 Stores CAL pointer and argument pointer, and 
picks up function code from argument string. 

Part 2 By getting proper function code in Part 1 and 
adding a JMP DSPCH, the CAL function is dis- 
patched to the proper routine. 

Part 3 This is the .SETUP CAL used to set up the PI 
skip chain or the API channel register. 

Part 4 Shows the API and PI handlers. It is suggested 
these be used as shown. 

Part 5 This area reserved for processing interrupt and 
performing any additional I/O. 

Part 6 Interrupt dismiss routine. 

Part 7 Increments argument pointer in bypassing argu- 
ments of ignored macro CAL's. 
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8.2.2 Example A, Skeleton I/O Device Handler 



/CAL ENTRY RoLJTIME: 




.GLOBL 


DEV, 


,me:d=3 






DEV, 


DAC 


DVCALP 




OAC 


DVARGP 




IS2 


DVARGP 




lac* 


DVARGP 




AND 


{77777 




1S2 


DVARGP 




TAO 


(JMP DSPCH 




DAC 


dspch 


DSPCW 


XX 






JHP 


OVINIT 




JMP 


DVFSAT 




JMP 


DVSEEK 




jHP 


DVENTR 




jMP 


nVCLER 




JMP 


DVCLOS 




JMP 


DVMTAP 




JMP 


DVREAD 




JMP 


DVWRTE 




JMP 


DVWAIT 




jMP 


DVTRAN 



/MUST BE or FORM AAA. 

/,MEO (MONITnR ERROR DIACwOSTIC) 

/SAVE CAL POINTER 

/AND ARGUMENT POINTER 

/POINTS TO FUNCTION CODE 

/GET CODE 

/REMOVE UNIT NO iF APPLICABLE 

/POINTS TO CaL*2 



/DISPATCH WITH 
/MODIFIED JUMP 



/I - 


. I N I T 


n » 


iFSTATi 


/3 = 


.SEEK 


/4 = 


.ENTER 


/5 = 


.Clear 


/6 5 


iCLOSE 


/7 = 


iHTAPE 


/10 = 


.READ 


/ll = 


.WRITE 


/12 = 


.WAIT 


/13 s 


,TRAN 



DLETE, .RENAH 



/ILLEGAL FUNCTIONS IN ABOVE TAPLE CODED ASl 
/ jMP DVERR6 

/FUNCTION CODE ERROR 

DVERR6 LAW 6 /ERROR CODE 6 

JMP« ( .HED*t /TO MONITOR 

/DATA MODE ERROR 

DVERR7 LAW 7 /ERROR CODE 7 

JMP» (,MED*1 /TO MONITOR 

/DEVICE NOT READY 

DVERR4 LAC (RETURN /RETURN (ADDRESS IN HANDLE^) 

/TO RETURN To WHEN NOT REAPY 
/CONDITION Has been REMOVED 

DAC* (,MED 

LAC (4 /ERROR CODE 4 

JMP« ( ,MED*1 /TO MONITOR 

/J/O UNDERWAY LOOP 

nVBUSY OBR /BREAK FROM lEVEl 4 

JMP» DVCALP /LOOP ON CAL 

/NORMAL RETURN FROM CAL 

DVCK DBR /BREAK FROM LEVLE 4 

JMP« DVARGP /RETURN AFTER CAl AND 

/ARGUMENT STRING 

/THE DVIMIT ROUTINE MUST INClUQE 
/A .SETUP CALLING SEQUENCE FoR 



!-ll 



/EACH FLAG 
/AND/OR Pi 
/THE SETUP 

DVINIT CAL 



CnNNECTED TO API 
A(AT SGEN TIME) , 
CALLlMG SEQUENCE iSl 



N 



/N = API CHAnNEU 
/(40 -77) , N s 
/TO API 



REGISTER 

ir NOT C0NNECTE(5 



16 
SKPIoT 



/I OPS ^UNCTION CoOE 
/SKIP lOT TO TEST THE 
/ADDRESS OF INTERRUPT 
/MANDUER (PI OR API) 



FLAG 



/THIS SPACE MAY BE USED FOR I/O SUBROUTINES 

/INTERRUPT Handler for api or pi 



ONUVl 


lAc 


(MOP 




dac 


DEVION 




oac 


DEVIOF 




DAC 


DVSWCH 




DAC 


IGNRPI 




JMP 


COMMON 


L't-'VPIU 


DAC 


DEVAC 




LAC» 


(3 




DAC 


uZvOLiT 




jMP 


COMMON 


uL'vI i^ 1 


jMP 


DEVPIC 




DAC 


DEVAC 




LAC 


DEVINT 




DAC 


DEVOUT 


IGNRPI 


JHP 


ONLYl 


COMMON 


OEVCF 




nEVION 


ION 





/SAVE AC 

/SAVElPCi UnK, BANK/PAGE MODE 

/AND MEMORY PROTECT 

/PI ENTRY 

/API ENTRYI SAVE AC 

/SAVEI PCi LINK, BANK/PAGE MODE 

/MEMORY PROTECT 

/LEAVE PI ALONE 

/ENABLE PI OR NOP 

/ENABLE PI OR NOP 

/THIS AI THE AREA DEVOTED TO PROCESSING INTERRUPT AND 
/PERFORMING ANY ADDITIONAL I/O DESIRED, 



DEVIOF 



lOF 
OEVIOT 



/DISABLE PI OR NnP 
/DIMISSAL BEFORE INTERRUPT 
/FROM THIS lOT OCCURS 



/INTERRUPT HANDLER DISMISS ROUTE 

DVOISM LAC DEVAC /RESTORE AC 

DVSWCH lON /ION OR NOP 

dbr /debreak and restore 

jMP» DEVOUT /LlNKs SANK/PAGE MODEi MEMORY 

/PROTECT 



/IF THE HANDLER USES THE AUTQl NCREMENT , 

/OR EAE REGISTERS! THEIR CONTENTS 

/SHOULD BE SAVED AND RESTOREDi FUNCTIONS 

/POSSIBLY IGNORED SHOULD CONTAIN 

/PROPER INDEXING TO BYPASS 

/CAL ARGUMENT STRING 

/ 

/CODE TO BYPASS IGNORED FUNCTIONS 

/ 



INDEX 



nVIGNS 



tSH 

JMP 



nVARGP 
DVCK 



/BYPASS FILE POINTER 
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8.2.3 Example B, Special Device Handler for AFOIB A/D Converter 



/ADC HANDLER 

/ 

ADSFS701301 /SKIP IF COnVERSIOM FLAG IS SET 

ADSC5701304 /SELECT AnO CONVFHT (ADC FLAG IS CLEARED 

/AND A CONVERSION' IS I^ITIAtlSED) 

ADRBa70l312 /READ CONVERTER RUFFER INTO AC A^JQ CLEAR FLAG 
/ 

.GLOBL ADC, 
iDXalSZ 

,MED = 3 /MED (MONITOR ErrOR OUgnjOSTIC) 
/ 

Aoc, OAC adcalp /sAvr cal pointer 

DAC ADARgP /and argument POINTER 

IDX aoargp /points tO Function code 

lac* ADARGP /GtT code 

IDX aoargp /points to CAL ♦ 2 

tad (JMP dspch 

DAC dSPCW /dispatch WITH 
DSPCH XX /modified JUMP 

JMP aDINIT /I'.INIT 

JMP ADIGN2 /2»,FSTat,,DLETE,,RFNAM 

JMP A0IGN2 /3«,SEEk 

JMP ADERR6 /4', ENTER 

JMP ADERR6 /5«, CLEAR 

JMP aDIGNI /6=, CLOSE 

JMP ADIGM /7*,MTAPE 

JMP aDREAD /I^s.REao 

JMP ADERP6 /lis, WRITE 

JMP ADWAIT /l2s,WAlT 

JMP A0ERR6 /i3s,-TRa\! 
/ 

/ILLEGAL FUNCTI0^JS IN ABOvE TABLE CODED AS 

/ JMP A0ERR6 

.EJECT 
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/FUNCTION CODE ERROR 

/ 

ADERR6 LAW 6 /ERROR CODE 6 

jHP« ( ,me:d*i /to monitor 

/DATA MODE ERROR 

ADERR7 LAW 7 /ERROR CODE 7 

JMP* ( ,MED*1 /TO MONITOR 
/THE ADINT RCUTI^E MUST InCLUOE a .SETUP 
/FOR EACH FLAG ASSOCIATED l^ITH tmE DEVICE 
/ 
ADINIT IQX ADARGP /I^^X TO pETURN BUFF SI?E 

.DEC 

lAC (256 

.OCT 

oac» 

IDX 

AOCMOD CAL 

AOCkSM 16 

ADCBP aDSF 

ADLBmP ADCU'T 

aDU\id LAC 

ADWC DAC 

ADWPCT JMP 



/STAMDARt; buffer Sl^r (DrCIMAL) 



aDArgp /return fT tc user 

ADARGP 

37 /5^ = API cHan^nEL 

/.Setup iOps Fu\cti-v.. cche 
/AtlC SKIP lOT 
/AODR, r)F INTERRUPT 

,*2 /SET-yP ni^CE OKL*^ 

aOCmcd /st<iP Set-up code if Mowt- 
adstgp /.inits aHF n0\E 



/ 

/STOP ADC ROUTINE CLFARS I'D UNnfRWAY SWITCH 

/ 

ADSTOP D?M aDUNH) 

JMP aDIGM /rEtupN) 

/ 

/THE PREVIOUS TAGS I \' THE CaL ArfA a«E jSED ^C^ 

/STORAGE DURING THE ACTUAL ,REAn FuNCTIO* 

/ 

/ADCKSM IS FDR STORING THE CHECKSUM 

/ADCBP IS THE CURRENT BUFFER POInTER 

/ADLRHP IS The LINE BUFFER HEADER POINTER 

/ADUND IS FOR DEVICE UNDFRWaV SwiTCH 

/ADWC IS USED AS THE COU^JTER 

/ADWPCT IS USED TO STORE CURRENT WoRD COUNT 

/ 

.EJECT 



!-14 



aowait lac 

SNA 
JMP 

/I/O Uf^OERWAY 
ADBlJSY DBS 

JMP« 
/ 
/ 

adreao 



ADUND 

aDIGnI 
UOOP 

aOcalp 



LAC 
S?AJC 

JMP 

DAC 

LAC* 

AND 

SZA 

JMP 

LAC* 

DAC 

OAC 

lOX 

LAC* 

DAC 

DZM 

0£M 

IPX 

lOX 



MA 



aDUmD 

adbusy 
adumd 

ADCALP 
(7200 

ADER«7 
ADARGP 
ADCBP 
ADLBHP 

aDargp 

ADARCP 

ADWC 

ADWPCT 

aDCKSM 

aDCBp 

aOCbp 



AOSC 
ADIGN2 lOX 
ADIGNl OBR 

JMP» aOARGP 
/INTERRUPT HANDLER TOR 
/ 
ONLYl LAC 

OAC 

DAC 

DAC 

DAC 

JMP 
ADCPIC DAC 

LAC* 

DAC 

.EJECT 



aDARGP 



(NOP 

adcion 
aocont 

adswch 

IGNRPI 
COMMON 

adcac 

AOCOUT 



/CHECK T 
/I^ MOT 
/jT WAS 
/SET IT 
/LOOK AT 
/BITS 6^ 
/lOpS Bl 
/NOi ERR 
/GET LiN 
/STORE I 

/Also St 

/iNCREMp 
/GtT -L. 
/STORE I 
/2ER0 Wo 
/?ERD Cm 
/G^T PAS 
/:\|0w PC I 
/BUFFER 
/START U 
/INCR, F 
/B^EAK F 
/RtTURNi 
API OR Pi 



SEE IF I/O IS UNDERWAY 
SET IT i^lTH -1 
SET, GO BACK TO CAL 

MODE 

S o^:i Y 

VARY? 
R 
BUFFER HEADER POINTEK 



Re it for later meade^ 

vT Af^^G, pointer 
^,W,C(2'$ COMP) 

T Tn word counted:? 

PO COUNT REG. 

fCkSU^' REG, 

T HEADER PAIR 

'jTlNG AT BEG INN IMG QF 

P DEVICE 
OR EXIT 
ROM level ^ 
AFTER CaL 



/SAVE AC 

/SAVE PC,UINK,EX. MODE 

/mEM.PRoTi 
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aDCInT 



IGNRPI 
COMMONJ 

adcicn 



JMP 

JMP 

DAC 

LAC 

DAC 

JMP 

ADRtJ 

ION 

OAC» 

IDX 

lOX 

TAO 

OAC 

1S2 

JMP 

LAC 

lAC 

SWHA 

RAR 

AND 

DAC* 

IDX 

TAD 

DAC* 

D2M 

JMP 

lOF 
AOSC 

/INTERRUPT Ha 

/ 

aDDISM LAC 

,eje:c 



ADCONIT 



COMMON 

AOCPIC /Pic ENTRY 

ADCAC /API ENTRY, SAVfc AC 

ADCIKT /save PC.LINKiEX.MODE 

ADCnuT /MtM.PROT 

eMLYl 

/READ Converter bufper 

/ENABLED Pic FOR OTWEs? DEVICES 

adcbp /store daTa in user puffer 
aDCbp /inc, Buffer poi^!ter 

aDWPcT /inc, WopO pair CnUjTER 

adcksm /add checksum 

adcksm /store it 

adwc /iJj I/O complete 

AOCO^T /nO keep Gop.'G 

aDwpct /yes, compute word Count pair 

/MAY BE rDD 
/TO TOP mALF 
/MAKE Wo, PRSi 
{377000 /8 BITS ONLY 

aolbmp /stqre in WEADER UX 
adlbhp /iNc, Tn Store cksum 

ADCKSM /ADD WORn PAIR COUNT 

aDLBmP /STORE IN HEADER #2 

ADUND /Cl-EAR DEVICE UNDERWAY 

aDDISM /e^it 

/DISABLE^ PIC OR NOP 

/BEFORE INTERRUPT FRHM TmIS iQT nCCURS 
NDLER DISMISS RTE 

aDCAC /RE-STORE AC 



ADSWCH 



ADCALP 

ADARGP 

ADCOUT 

ADCAC 

/ 



ION 
DBR 
JMP* 

■0 

?i 


.END 



/iom or nOP 

/Oc-BREAk AKip RESTORE 
aDCouT /lINK#Ex.MO0EiMEM,PROT 

/ADD cal Pointer 

/aUd argument POINTER 

/pC,l,fh,mp 

/AC SAV^n WERE 
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CHAPTER 9 
XVM/DOS BATCHING FACILITIES 



(To Be Supplied At A Later Date) 
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APPENDIX A 



DECTAPE "A" HANDLER (DTA.) 



The following simplified charts describe the approximate flow of control 
through the DECtape "A" Handler. 



A-1 



(Entry from^\ 
CAL Handler j 



JSiL 



Save pointer to CAL 

Save subfunction or data mode 




Get function code, and make up 
dispatch instruction 








Next Page 



A- 2 



From Preceding Page 



ERROR 
lOPS 55 




Set up word pointers within the new 
buffer — e.g., buffer+377 = link 




( B J .INIT (Function Code #1) 






1. Give user standard buffer size (377) 

2. Set input or output file indicator 

3. Wait for previous I/O to finish for 
DEC tape 




1. Do .SETUP to API and Skip Chain 

2. Test buffer size. If not 440 
or greater, terminate with an 
lOPS 70 



8 



3: 



Return to 

user after 

CAL 



A- 3 




(.OPER, Function Code #2) 



ERROR 
lOPS 6 



Dispatch to requested sub- 
function and process 



Exit to 
user after 
^ CAL 



(Loop back to user CAL) 



<- 




(.SEEK, Function Code #3) 



ERROR 
lOPS 10 



ERROR 
lOPS 7 



Bring directory into core, if not al- 
ready in 




ERROR 
lOPS 13 



1. Obtain starting block nxjinber 

2. Read the first file block into core 



Return to 

user after 

CAL 
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(Loop back to user CAL. ) <- 




g ). ENTER (Dispatch Code 4) 



ERROR 
lOPS 7 



Bring Directory into core, if not 
already in 




Set indicator so that file is deleted 
upon a .CLOSE to this .DAT slot 



:-± 



Search directory bit map (in core) for first free block 




ERROR 
lOPS 15 



Set up to write out this block, when 
the time comes 



Exit to 
user after 
CAL 



(Loop back to user CAL.) ^ 




.CLEAR 

(Dispatch Code 5) 



ERROR 
lOPS 10 



1. Clear out file bit maps 

2. Clear directory block with the SYS 
block bits set in the directory map 



S 



Exit to 

user after 

CAL 
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.CLOSE 

(Dispatch Code 6) 



(Loop back to user CAL) ^ 



J± 



1. Clear bit in bit maps 

2, Clear switches 




1. 



2. 



Put End-of-File 
indicator in buffer 
Write out last block 
in file 




The following is done on 
the in-core bit maps: 

1. Zero its bits in the 
directory bit map 

2. Overwrite its file 
bit map with the 
new one 



<- 



Write out updated directory and file bit map 



Return the buffer to the 
system 



r Return to >. 
user after ) 



Return to 
user after 

V CAL y 
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(Loop back to user's CAL) 



<- 




.READ 

(Dispatch Code 10) 



Pass 001005,776773 
sequence to user's 
buffer 



N 



L Transfer line to user's 

buffer 
2. Set data validity bits 



<r 




Set EOF indicator 



\C 



Read in next block of file 



■> 



Exit to 

user after 

CAL 
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Loop back to user's CAL^ 




.WRITE 

(Function code 11) 



Set "write executed" 
switch 




1. Write out block; 2. search for next block 




ERROR 
lOPS 15 



■> 



1. Transfer user buffer to handler 
buffer 

2. Compute Checksum 




N 



EOF 



Transfer the block 



'' Exit to \ 
user after J 
^__CAL_^ 




.WAIT & .WAITR 
(Function Code 12) 



Set CAL pointer to specified address 



Jk. 




^ 



1/0^^^ Y 
inderway 



Exit to 

user after 

CAL 



Exit via 
CAL Dointer 
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Loop back to user CAL <- 




.TRAN 

(Function Code 13) 



1. 


Set up block to transfer in or out 


2. 


Set up core address-1 


3. 


Set up word count 


4. 


Start transfer 




V 



Exit to 

user after 

CAL 



INTERRUPT SECTION 



Stop tape 




(Entry from ^ 
PI or API J 



Save information 
to restore later 



Read status register "B 







Y ^ Right 
^direction^ 

^^ 

Change direction] 



UghtV^Y 
'direction' 



■> 



Change direction 



et up Current Address & 
ord count for read or 
rite 



-<- 



Set up current address 
and word count for 
search 
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(ERROR Logic) 





On 

>^Search^ 



ERROR 
lOPS 12 



Change 
direction 



Try 
again 



^__Y^^'^rity\N 
^s^rroj,/^ 





Try 
again 



1. Accept data as is 

2. Get rest of data 




ERROR 
lOPS 12 




±. 



1. Read Status Register "A" and 
save it 

2. Clear Status Register "A" 

3. Disable interrupts 

4. Set return in .MED (register 3, 
bank 0) 

5. Clear I/O underway switch and 
enable CTRL P 



.MED 



Give lOPS 4 



±. 



1. Set I/O underway switch 

2. Set up Current Address and 
Word Count for search 



Start up DECtape 



■>■ 



_^ 



1. Restore PIC interrupt entry and AC 

2. Turn interrupt on, if this was a PIC 

3. Debreak and Restore 



Exit to 

interrupted 

code 
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APPENDIX B 



DISK "A" HANDLERS 



The following simplified charts describe the approximate flow of control 
through the Disk "A" Handlers. 



B-1 



/^ Entry from \ 
— -Z>{ CAL Handler ) 



M. 



1, Save the pointer to the CAL 

2. Save the .DAT slot n\iinber and subf unction 
code (bits 5-8 of LOC+0) 




Do .SETUP for PI and API interrupts 




RK 
Disk 



\k 



<r 




RF 
disk 



¥. 



Determine number of platters 



\!/ 



Set up Stan- 
dard TCB 
format in 
the RKTCB 





I0PS21 



Calculate the maximum block number, for use 
at .CLEAR time 



^ 



Calculate size of the TEMP list for pre-allocated 
blocks, and set the BUF.OK switch (SGEN size ok) 



Branch to ^^ 
user's CAL 




' WAIT 



f 



— Fall through to "10. OFF* 



Next Page 
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From Preceding Page 



i 



il. calculate pointers to the arguments of the CAL 
2. Save step counter and MQ for EAE 




Save current set] 





B \ (DISPCH) 




the current set in its appropriate buffer 



Make 



new .DAT slot the "current" one 




A 



FINDBY 



Find or set up 

the Busy Table 

entry for this 

.DAT slot^ 



Save status of Write Check"] 





TRAN 



Next Page 
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From Preceding Page 




^ Buffers 
large enougff" 




lOPS 70 



Request a buffer (.GTBUF) 




lOPS 55 



1. Save pointer to buffer, and zero entire buffer 

2. Complete the Busy Table entry 



1. 
2. 
3. 



Get UIC from the Busy Table entry 
Bring in the Current Set from buffer 
Set up pointers to: User's Directory Entry, tem- 
porary block list. Data Block Words 0,1,2,3,376 s 
377 




.TRAN, .WAIT and .WAITR 
have already been inter- 
cepted. 
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1. wipe out entry in UFD, and 

2, Give back pre-allocated blocks 



1. Return any allocated buffer 

2. Zero any old busy table entry 

3. Make a new entry in the busy table 

4. Save Write Check bit in busy table 

5. Indicate "current" .DAT slot is 
zero 



Exit to 
LOC+4 




Next Page 
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From Preceding Page 



.DLETE 



1 



Search for file 



Found >>^^ > 



lOPS 63 




AC=0 



1. Delete the file 

2, Give back all 
blocks 



1, Return aquired 
buffer 

2, Make "current" 
.DAT slot zero 



Exit to 
LOC+3 




(Found) 




(.FSTAT) 



1. Place device type in LOC+2 of CAL 

2, Search for file 



1* 


Place file size in 




LOC+3 


2. 


Read in first RIB 


3. 


Move RIB to top of 




buffer, if neces- 




sary 




1 




Found 



\L 



Load AC with first 

block number 
1 




Zero the AC 



lOPS 



Exit to 
LOC+3 



Exit to 
EXITAD 
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(.RTRAN) 




lOPS 11 



relative 
block number 
£ number of 
'file blocks' 



lOPS 66 



Calculate RIB block niimber, and the desired pointer's 
position within that RIB block 




Depending on the location of the desired block, rela- 
tive to the RIB block in core, read in the next or 
preceding RIB block 




Save pointer to desired data block 



RF. 



M. 



Store starting word number and the number 
of data words desired 



lOPS 67 





RF or 
RP/RK 



RP/RK 



Assume transfer starting at word zero, 
through word 375, and set parameters 
accordingly 



Set direction switch 




Input 




MORET] 



Use word count given in CAL during disk 
pack input 
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Set up user's buffer to receive the link words for block 



N - no forward lin: 





Set both link 
words to -1 



- no backward link 



Set links in data block from adjac- 
ent pointers in the RIB block 



Set backward link to 
adjacent pointer in 
RIB, and forward link 
to -1 



\^ 



Set backward link to 
adjacent pointer in 
RIB block 

2, Read in next RIB block 
and adjust RIB number 
indicator in the cur- 
rent set 

3. Set forward link to 
first pointer in the 
new RIB block 




1. Set forward link to 
adjacent pointer in 
RIB 

2. Read in previous RIB 
block and adjust RIB 
number indicator in 
the current set 

3. Set backward link to 
last pointer in the 
new RIB block 



Set forward link 
to adjacent poin- 
ter in RIB, and 
backward link to 
-1 




Set up driver with the 
correct block number 



Set up driver with the 
correct word number 

J " 



Bring in or send out 
required block or data 



Exit to 
LOC+5 
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lOPS 10 



ERROR 



lOPS 13 
51 or 71 



lOPS 10 



^ 

U 



lOPS 64 



Read in first block of file 



Exit to 
LOC+3 
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lOPSlO 



FINDER 
Search MFD and UFD 
START = Pointer to 
SAT word 3 



(No entry in MFD 
for this UIC) 




1 

(Entry in MFD, but 
UFD is empty) 




(UFD exists, but does 
not contain a file by 
the given name) 




(UFD exists, and con- 
tains a file by the 
given name) 




1. Save number of the last MFD block read 

2. Save file name 



ENTSET V 
Preallocate \ 
some blocks / 



Jl 



Read in last MFD block 



Set pointer to free slot 
found by FINDER 





Read it in 



GETNXT 

Get next 

block number 



Make forward link of last MFD block 

point to the next block 

Write out the block 

Clpar tht> hnffpr 



1. Set up entry pointers """ 

2. Insert new UIC, entry size and zero protection 
code (unprotected) into new MFD entry 



7^ 

fMFDSE*^ 



*That is, has a .RAND, .SEEK or 
.ENTER been issued without a 
.CLOSE? 
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CKDIRP 
Is directory 
protected? 



IOPS63 



N 



ENTSET 
Preallocate 
some blocks 



MEDSE-n- 



Read in the MFD block 
which contains proper 
entry 



GETNXT 
Obtain a block 
for the UFD 



Set up entries in the Busy Table, the 
flFD block and the Current Set 



Write out. the MFD block and clear the 
buffer 



1. Set up a new UFD block in the buffer, 
with a back link of -1 

2. Set pointer to indicate location to 
receive the new entry 
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WIPOUT 
Remove file 
entry from 
Sthe UFD 




Set "Old file in" switch 
Set pointers to UFD block 
nxiirber and the first word 
of the olri file's entry 
(to be used at .CLOSE) 




f CKDIRP N 

Check directory 
^protection > 



Protection 



IOPS63 



Violation 



OK 



f ENTSET \ 
Preallocate 
vsome blocks' 



Read in first UFD block | 




I 



SEARCH 
Look for 
a free 
entry 



:k. 



1. Read in UFD block with 
free entry 

2. Load "UFDl" pointer in 
Current Set with this 
block number 




1. Change forward link of last UFD block 
(still in core) 

2. Write out last UFD block 
■^ Clear user's buffer 
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1. Save pointer to new UFD entry in "UFD2" of the Current Set 

2. Set up pointers to UFD entry slots 

3. Store file name and extension in the UFD entry 



f GETNXf" 
Obtain a 
,RIB block 



1. Store RIB pointer in UFD entry 

2. Store protection code s date 

3. Insert data block number 

4. Write out UFD block with entry 

5. Clear buffer 



BLDRIB 
Set up 
the RIB 



I Set "WREXSW" (Write-executed switch) 



GETNXT 
Obtain a 
ata bloc: 



Clear . the buffer to zero 



Return 
to user 
After CAL 



ENTSET 



1. Read in the first Submap 

2. Make it the "Current Map" 

3. Zero indicator of the n\imber 
of preallocated blocks 



LSTFIL 
Preallocate 
some blocks 




(Number of blocks pre-allo- 
cated is the minimum of 
number available and the 
size of the "Temp List") 



Return any preallocated blocks 



RETURN 



I0PS15 
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IOPS63 



1. Clear a buffer 

2. Set words 0, 1, 2, 376, and 377 to -1 

3. Set bits 0-2 of word 3 to MFD size 

4. Sot bits 3-17 of word 3 to noint to 
first submap 

5. Write out buffer to block 1777, if 
RF/RK or 47040 if RP 

6. Clear the buffer 



(How the handlers ^i/rite out , the bit mans) 



RP/RK 



2k. 




1. Set up forward and backward links in buffer 

2. Set up words 0, 1 and 2 

3. Turn on bit in this submap corresponding 
to itself 

4. Write out the block 




± 



1. Set backward and forward links to -1 

2. Turn on bits that correspond to MFD 
block and first submap block 



Set bit in appropriate bit map for MFD 




1. Set bit in the first bit map that 
corresponds to second bit map 

2. Sot forward link to next block 

3. Write out the buffer and clear it 

i. ^/»_w iJ^^v,^w j.^Lt?i. »,o i.j.i.ov_ Su^iiicip, am. 

forward link to -1 



> 



)k. 



Write out the buffer 






Return to 
user 
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From Preceding Page 




Reset RIB block pointer in 
UFD to last data block 



Set "word in RIB" in UFD 




WRTUFD 



Write out current UFD block 




1. Write out UFD block currently in core 

2. Reset UFDl to UFD block with old file 

3. Read in the UFD block with the old file's 
entry 



SAMUFD 



1. Reset UFD entry pointer (UFD2) 

2. Wipe out the old file's entry 



(Give back any unused blocks) 



UNUSED 



Read in first RIB block used 
Save the forward data link 



Next Page 
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Set for internal looping 
(implicit WAIT) until done 





N 



1. VJrite out current block 

2. Obtain another and 

3. Clear the buffer 
(Subroutine SETWRD) 



<r 



1. Write 2-word EOF line in buffer 

2. Set forward data link to -1 

3. Increment file siz-e 




I TRAN RIB words into last data block | 



RNOFIT 



^ 



Write out last data block 



1. Read in UFD block for this file 

2. Fill in file size and turn off 
Truncated file bit 

3. Save pointer to first RIB block 



Next Page 
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From Preceding Page 



Was 



still in core.) 



y^ last data \ 


^^ 






*\hlock used for' 






Reset RIB Block pointer in UFD to 


last Data Block 






INFPRO 










t 








Set 'Word-in-RIB' in 


UFD 




omplete. UFD 


is 


( 








1. Write out UFD currently in core 

2. Reset UFDl to UFD block with the 
old file's reference 

3. Read it in 



M- 



SA.MUFD 



1. Set UFD2 to old file's entry slot 

2. Wipe out the old entry 



(Give back unused blocks.) 



V 



1. Get first RIB block used 

2. Read it in 

3. Save the forward data link for loop 



Should 

any blocks 

be given back from 

any RIB block 

used 



Next'^Page 
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From Preceding Page 




1. 



2. 

3. 
4. 



Find area in this block where 
blocks should be given back 
Adjust word of this block 
to reflect only those used 
Write out the block 
Fudge subroutine LSTFIT; so it 
appears UNBUSY called 



f LSTFIL 

(Actual transfer 
vis to LSTMOV) 





Turn off RIB block's bit in SAT 
and write out the Submap block 



[Set Return to L0C-f2| - 



^ UNBUSY 



<- 



1. Perforin .GVBUF 

2. Zero current set 

3. Make "current" 
.DAT slot zero 



M. 



Return to 
LOC+2 
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Set up return address 




I0PS6 



MAXSET 



^ 



Save pointer to "next" record 




Read in previous block 



CBLOK 



Position record pointer to 
top of the buffer 




Use this record's word pair 
count to point to the next 
record 
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SETUP 
Check Header word pair 
Set up the word pair 
counters for moving data 



non-Dump 
Mode 




LINFIT 



Make Word Pair Count 

negative 

Zero checksum word in 

record to be read 

Clear line error flag 




' PWORDS \ 
Pass record 
.to user > 




1 Set pointers for a ski^^ ov€ 
the next record 

2. Set "Short Line " Flag 

3. Set return in PWORDS to go 
to ENDINl 



PWORDS 
Skip rest 
of line 
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KDUMPlj 



Set up "words left 
in data buffer" for 
PWORDS 




Set appropriate 
error bits, if 
any 



PWORDS 

Read to end of 

record or to end 

of data block 




Read in next data block and 
set up pointers, anticipat- 
in the next read 
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READ-vmiTE Coirmon Setup Routine 



1. Save pointer to argument data block 

2. Set up return address 

3. Set pointer to checksum word in data buffer 

4. Save checksum word 




lOPSll 



1. Set up pointers to "receiver" data buffer 

2. Index SETUP return pointer past arguments 
to Dump Mode exit 

3. Save Word Count from CAL 




Indpx return pointer to Non-Dump Mode 



Return 



' GETWPC ' 

Extract Word Count from line 

ibuf f er header word pair y 



\^^ 



w . p-r- . 



or w.p.c, 
y 111- 



( RETURN j 



IOPS23 
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1. Set up return address 

2. Clear "Current Slot" 
number 

3. Get Word Count 




1. Set up for input or output 

2. Get argument block number 

3. Read it or write it 
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lOPSll 



SETUP 
Set up word counter 
and data buffer 




Move in all 
that will 
fit and ad- 
just argument 
size count 



JL 



( SETWRD^ 



NOFITl 



( 



Jl 



SETWRD 



PWORDS 
Pass the record 
to the handler • s 

buffer 




) 



Set "receiver pointers 
to the top of the 
buffer 



fAW0RD3 
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(Loop on CAL) 




Go to 

Argument 

address 



RETURN 
to LOC+N 
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1. store niimber as forward data link 

2. Save current block number 




I0PS15 



Write out buffer and then clear it 
Increment FILSIZ 




J^ 



Make this number cBrrentj 




I0PS15 



Return 



^ LSTFIL^ 



±_ 



BLDRIB 
Set up 
the RIB 




,,DSMIiL. 



Set next block 
number in TLIST to -1 



SETBAK 



Set baclcward data link returned from SETWRD | 



RETURN 
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1. Initialize the map count num- 
ber, block count, TLIST 
pointers and TLIST count 

2. Read in the current submap 




Compute starting location for search 



1. Start filling the Temp List 

2. When find a free block, skip 
the next block+DELTA (assem- 
bly parameter) and continue 




Temp List 



Start at bit word 3 
I 




Read in next Submap 



±- 



EXIT 
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COMMON ROUTINE FOR READING AND 
WRITING TO AND FROM THE DISK 



1. SAVE THE CALLING ADDRESS 

2. GET THE ARGUMENTS 

3. COMPUTE DISK HARDWARE 
BLOCK NUMBER 

4. SET I/O UNDERWAY FLAG 




SETUP TCB AND 
CALL PIREX 
TO START DISK 
DISK I/O 



INT 
(INTERRUPT 
. HANDLER) 



1. SAVE PC AT EXITAD 

2. SAVE AC 

3. TURN OFF I/O UNDERWAY 
FLAG 

4. LOWER PRIORITY TO 
LEVEL 4 




1. CLEAR DISK FLAG 

2. PROCESS ERROR 

3. IF NECESSARY, 
RETRY 10 TIMES 




EXIT 



ATTEMPT RECOVERY 
ON CTRL R 



DISK "A" HANDLERS 
B-28 



APPENDIX C 
PROCEDURE FILE 



ASG 

1 ASSIGN DEVICE UlC TO .OAl 

\ gD00(9Dll()^)@ <!aU00C&^D12()(a)@> aAOOOe 

ASM 

2 MACHJ AND LINE EUlTUH 

A 3D00ODll()&)@ <fdU0u(^D12C )[d)(a> -1 4/@D03 ( @D1 1 ( K^ ) f^ <lsiUu3 ( @01 2 ( ) a J ia> -15 

B.PKE 

3A00(FlLTiMP)g 

(aA03C@A00(FILTMP)(ajid 

A ?O00C@Dll()Cd)@ <rdU0U(rdD12( jLa)?> -11/LdDOl (I?D11( )td)id <^U01 ( L^Dl 2 C ) a ) (a> -10 

A aD02OUllC)(a)L^ <@U02C[dD12( J!a)a> -14/?005(SiDl 1 C ) a j (a <iaU05(i3012( 3 ■?) §> -13 

A faD04CLP)fa <@U04(aD12()a)(a> -12 

MACRJ 

00 C BL ) id.^AOO ( FIL IMH ) §C°D1 4 ( ) i? 

BNK 

14 BANK MODE OPERATiUN-ON 
BANK UN 

BUF 

1 NUMBER OF BUFFERS 
BUFFS !aA00(4)g 

CHN 

1 SPECIFY 7 OH 9 TRACK MAGTAPE 
C SAOOOia 

CMP 

1 SOURCE COMPARE 

A @D00(@D11()§)@ <yU00(@D12C)@)@> - 15/&D0 1 ( @D1 1( 3 a } g <^U01 ( 9D1 2 C ) ?) @> -14 

SR^, C uM 

@Q( Ji-i-^AOOOg/^AOl ()@&U14( )i? 

DIR 

1 LIST DIRECTORY 

PIP 

L LP.^AOOC^DllOg)^ <@U00C§iD12()§)§>&D14()^ 
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DLG 

2 LOGOUT UIC 
LOGOUT 

DMP 

01 DUMP UTILITY - EXPANDED SUB FILE 

A ?DOOC@Dll()e)§ <auOOC@D12()@)@> -14/@D01 (LP) 6 <(aU01 C§D12 ( ) @) a> -12 

DUMP 

@A00(ALL)@^D14( ) P 

DOS 

l,i, GENERAL PRC FILE FOR GIVING COMMAND STRINGS 
^AOO(9D14()0)g 

FIL 

2 CREATE A FILE FROM CARDS/EDITOR 

A 0000(^0110^)^ <@U00(CdD12()@)?> -14 

A @D01ODll()@)e <@U01(^D12()S)?> -15 

B.PRE 

@AOO(FILTMP)@ 

3A01(&A00(FlLTMP)e)C4 

FOR 

2 FORTRAN IV AND LINE EDITOR 

A iaDOO(eDll()P)@ <@U00(§D12()^)P> -14/@D01 ( aoi 1 ( ) (a) § <@U01 (@D1 2 ( ) @) e> -15 

B.PRE 

C^AOO(FILTMP)P 

@A01(@A00(FILTMP)§)a 

A @000(@Dll()P)g <@UU0(§D12()@)9> -ll/@D03(CdDll()Cd)C«i <^U03 (@D1 2 ( ) ^ ) !3> -13 

A ?D02(LP)§ <§U02(^D12()§)?> -12 

F4 

@O(BL)9«§A00(FILTMP)@&D14()& 

JOB 

2 START NEW JOB 

LOG JOB »A00(3& BEGIN ^D14()9 

T 

LOGIN @A02(SCR)(a 

A NON 2,3,4,7,10,ll,12a3»14,15,16,17,20/@Dll()gi 1 

PIP 

N 9D11C)& <SCR>§D14()@ 

?A03()e 

KEEP ?A04(0FF)§ 

TIMEST 9A01(1)@:00 
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KEP 

1 RETAIN DEVICE ASSIGNMENTS 

KEEP &A00(ON)§ 

LCM 

13 SUPPLEMENT TO LIB PRC-UPDATE ,LIBR 
@A00CCLOSE@D13C)^)@ @A01 ( @D1 3( )?)@ &A02()& 

LIB 

1 

A ^DOOCaDllOP)^ <@U00C@D12()@)§> -14 

A 3D01C§D00(@Dll()rd)^)P <@U01(§U00C§D12C)@)§)@> -15 

A @D02(aDll( ja)a <§U02CgD12( )§)§> -10 

A ?D03(LP)@ <iaU03(tdD12C)@)@> -12 

UPDATE 

gOCLUS)e„^A0O(.LlBR)§§D14C)@ 

LNK 

13 DIRECT SUB FILE - BUILDS LINKS FOR EXECUTE FILE-USE rtlTh OVL PRC 
§A00CI^D14()@)^&D14()@ 

LOG 

2 LOGIN UIC 
LOGIN ?AOOCSCR)@ 

LST 

2 LIST CONTENTS OF FILE ON LINE PRINTER 

PIP 

T LP-PD00(§D11()§)@ <@U00(§D12()§)e> §AOO(FILTMP)@ CA)@D14()? 

MAC 

2 MAC-ELEVEN AND LINE EDITOR 

A 0DOO(§D11()@)& <@U00(§D12()e)9> -14/§D01 ( @D1 1 ( )ij»)» <&U01 C@D12 ( )§) @> -15 

B.PRE 

gAOO(FILTMP)g 

@A01C&A00CFILTMP)§)@ 

A laDOOCeDllC)?)^ <@U00(gD12C)e)e> -11 

A @D02(LP)§ <&U02(^D12()&)?> -12 

MACll 

&O(BL)@«§A00(FILTMP)g§D14(J9 
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MAP 

l;3 DIRECT SUB FILE FOR CHAIN OPTION AND RES CODE ONLY 

CHAIN 

^A00CTMPXCT)P§D14()& 

@A01(SZ)@iaD14()@ 

@A02(FILTMP)§gD14()e 

&D14()e 

MIC 

2 LOGIN MIC UIC 
MICLOG 9A00()§ 

MNT 

1 MOUNT TAPE# ON DRIVE # 

LOGW MOUNT §0(D)&-TAPE# §A00()& ON DRIVE* 9A01()@ - WRITE PA02(LOCK)e 

MSG 

13 MESSAGE TO OPERATOR-DIRECT SUB FILE 
LOG ^AOOOe 

MSW 

13 MESSAGE TO OPERATOR W/WAIT-DIRECT SUB 
LOGW @A0OC)@ 

NDR 

1 CREATE NEW DIRECTORY 

PIP 

N 9A00(@Dll()§)e <@U00C§D12()§)@>§D14C)@ 

OVL 

13 DIRECT SUB FILE - USE FOR BUILDING OVERLAYS(CHAIN) 

§A00(TMPXCT)@§D14()@ 

@A01(SZ)9§D14()§ 

9A02CFILTMP)^§D14()& 

PAG 

1 PAGE MODE OPERATION-ON 
PAGE ON 
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PRT 

1 SPECIFY PRUTECTIUN CUDE 
P aA00(2)§ 

RUN 

2 RUN 
F4 

BL.iaAOOOra C^f)14()y 

CHAliM 

OAOOC )3liiD14( )id 

MM^aD14C )§ 

(aA00C)@@D14( )(d 

?D14()ca 

E :aAOO()ld 

QDP 

i IJIHP COHt: On TERMIiJAI. tHKURS-MO ARGUMENTS 
vJOIIMP 

XCT 

2 EXECUTE 

A LdDOOC^DlU Jid)(d <:dU()0(Cn)12( )(a)ja> -4 
E faA0OCTMPXCT)?a 

XVM 

1 XVM MODE UPEHATION (Jrj/f)FF 
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INDEX 



Abort I/O transfer, 2-10 
Absolute constants, 3-2 
Additions to the nonresident 

monitor, 4-4 
API (Automatic Priority Inter- 
rupt) , 2-6, 3-3, 3-10, 8-1 
hardware channel registers, 

8-4 
software interrupts, 2-25, 
2-27 
Appendages, monitor, 3-2 
Autoincrement register, 8-5 
Auxiliary routine, 3-4, 3-10, 
3-11 
API-version scheduler (figure) 

3-11 
non-API-version scheduler 
(figure) 3-13 



Bad allocation table (BAT) , 7-18 
Block preallocation, 7-16 
Blocks, 5-4 

and tables, 5-2 
Bootstrap, 

manual, 3-1 

system, 2-16 
BOSS XVM mode operation, 5-2 
Buffer allocation, 5-6 
Buffer, disk (figure) , 7-15 
Buffer pool, 6-14 
Buffers, 7-14 



Calendar date (SC.DAY) , 2-2 
CAL entry to device handler 

(figure) , 8-2 
CAL handler, 3-3 

(figure) , 3-5 
Checksum, 7-4 
Clock interrupts, 3-3 
Clock oriented .SCOM locations, 

3-20 
Clock routines, 3-14 
Code, initialization, 3-2 
COMBLK, 6-1, 6-9 

(figure) , 6-8 
Commands, nonresident monitor, 

4-5 
Commands that obtain and/or 

return buffers, 7-14 
Constants , 

absolute, 3-2 
relocatable, 3-2 
Control character interrupts, 

3-3 
Control character routines, 2-8 
Core, 3-1 



Core dump, 2-17 

Core image, 2-18, 5-1 

truncated, 2-18 
Current set, 7-16 



Data organization, 7-4 
Data recording, 

director led, (MTA. , 

MTC. ) , 7-5 
nondirectoried (MTF) , 7-5 
.DAT slots, 5-2, 5-6 

table, 6-9 
DECtape "A" handler (DTA.) 

(flowcharts) , A-1 
DECtape directory (figure) , 7-2 
DECtape file organization, 7-1 
DECtape/magnetic tape differences, 

7-4 
Device assignment table (.DAT), 

6-13 
Device handlers, 5-1 

I/O, 3-3, 8-1, 8-7, 8-11 

PI and API entries to (figure) , 

8-3 
UNIBUS, 8-9 

writing special I/O, 8-7 
Device table, 6-12 
Directoried data recording 

(MTA. , MTC.) , 7-5 
Directoried DECtape, 7-1 
Directory bit map, 7-2 
Directory entry section, 7-2 
Disk "A" handlers (flowcharts) , 

B-1 
Disk buffer (figure) , 7-15 
Disk file organization, 7-14 
Disk file structure, 7-12 
Disk-resident blocks, 6-1 
Disk-resident changing block, 

6-10 
Disk-resident tables, 6-12 
Dump mode, 7-4 



EAE registers, 8-5 
Exec mode, 3-10, 3-14 
EXECUTE, loading (figure), 5-3 
Expanded error processor, 2-14 



File bit map blocks (figure) , 7-3 
File buffer transfer vector 

table, 6-14 
File labels, user, 7-9 
Filenames in labels, 7-10 
File structures, 7-1 
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File structures (cont.)^ 

disk, 7-12 
File transfer, 2-17 
Flags, 2-18, 3-26 



GET CAL function, 2-17 



Handler name, 6-10 
Handlers, 6-13 

disk "A" (flowchart) , B-1 
system loader disk, 5-1 
UNIBUS device, 8-9 

see also Device handlers; 
I/O device handlers 



Image mode, 7-4 
Index register, 8-5 
Initialization code, 3-2 
Initializing .SCOM, 3-1 
Input/output communication 

(IOC) table, 6-13 
Instructions, 3-2 
Interrupts, 2-6, 3-3, 8-4 
Interval timing (SC.ETT) , 2-3 
I/O aborted, 2-10 
I/O device handlers, 3-3, 8-1 

example, 8-11 

writing special, 8-7 
lOPS ASCII, 7-4 
lOPS binary, 7-4 
lOPS error processor, 2-11 
I/O transfers, continuous, 7-10 



Linking loader (figure) , 5-3 
Loading resident monitor, 3-1 
Loading system programs, 5-1 



Magnetic tape, 7-5 

Magnetic tape/DECtape difference, 

7-4 
Magnetic tape file directory, 

7-7 
Magtape file structure (figure) , 

7-8 
Manual bootstrap, 3-1 
Mass storage busy table, 6-14, 

6-15 

i'ldouci. i-xxc U.XJ. tiu i_oj.y vi'iruj , 

7-12 
.MED error processor, 2-12 



Mini-ODT, 2-22 

commands, 2-23 
Mnem.onics, 6-1 

for I/O devices, 6-10 
Monitor appendages, 3-2 
Monitor, nonresident, 4-1 

(figure) , 4-2 
Monitor, resident, 3-1 
.MTAPE commands, 7-1 
.MTRAN system macro, 2-15 



Nondirectoried data recording, 

(MTF) , 7-5 
Nondirectoried DECtape, 7-1 
Nonresident Monitor, 4-1 

additions, 4-4 

comm.ands , 4-5 

initialization (figure) , 4-2 
Nulls in .SIXBT text, 2-12 



Overlay table, 6-12, 6-15 
.OVRLA, 6-12 



Patching facilities, resident 

monitor, 2-24 
PI and API entries to device 

handlers (figure) , 8-3 
PIC interrupt service routine, 

8-8 
Poller, UNICHANNEL, 3-21 

(figure) , 3-23 
Pre-allocation of blocks, 7-16 
Procedure file, C-1 
.PUT CAL function, 2-17 



Real time clock, 3-14 

routines (figure) , 3-15 
Recording, staggered, 7-1, 7-3 
Relocatable constants, 3-2 
Request flags, 2-27 
Reserved address locations, 6-15 
Reserved word locations, 6-14, 

6-15 
Resident monitor, 3-1 

patching facilities, 2-24 
Retrieval information block (RIB) , 
7-14 

(figure) , 7-15 
Routine, auxiliary, 3-4, 3-10 
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SAT - see Storage Allocation 

Table 
SC.DAY (calendar date) , 2-2 
SC.ETT (interval timing) , 2-3 
.SCOM, initializing, 3-1 
.SCOM location (SC.TCB), 2-19 
.SCOM registers, 5-1, 5-5 
.SCOM table, 6-1, 6-2 
SC.TIM (time of day) , 2-1 
SGNBLK, 6-1, 6-9 
(figure) , 6-11 
Skeleton I/O device handler, 

8-11 
Skip chain, 6-13, 8-4 

table, 6-10 
Software interrupt, 3-4 
Staggered recording, 7-1, 7-3 
Storage allocation tables 

(SATs) , 7-17 
Storage retrieval on file- 
structured magnetic tape, 

7-11 
Submaps, 7-17 
SYSBLK, 6-1 

(figure) , 6-8 
System bootstrap, 2-16, 5-1 
System communication (.SCOM) 

table, 6-1, 6-2 

see also .SCOM 
CDysTceiu intfcjgiity, ^- 1 r ~>~~>i j~j-w 
System loader, 5-1 
System loader disk handler, 5-1 
System parameters, 6-9 
System program loader (figure) , 

5-3 



User File Directory (.UFD), 6-13, 

7-12 
(figure) , 7-21 
User file header label format 

(figure) , 7-9 
User file labels, 7-9 
User identification codes (UIC) , 

7-12 
User mode, 3-10, 3-14, 3-26 



Word locations, reserved, 6-14, 
6-15 

Writing special I/O device han- 
dlers, 8-7 



XVM mode, 2-16, 3-26 
.XVMOFF CAL, 2-17 
.XVMON CAL, 2-17 



Tables, 5-4 

Tables and blocks, 5-2 
Tables, disk-resident, 6-12 
Task control blocks, 2-19, 2-21 
Temporary tables, 6-14 
Tim.e of day (SC.TIM), 2-2 
Timeouts, 3-22 

•TIMER interrupt routine, 2-3, 
3-10, 3-14 
deactivated, 2-8 
using without API, 2-6 
Timing mechanisms, 2-1 



UC15 OFF command, 2-19 
UC15 ON command, 2-19 
.UFD table, 6-9 
UNIBUS device handlers, 
UNICHANNEL poller, 3-21 
(figure) , 3-23 
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READER'S COMMENTS 



NOTE: This form is for document comments only. Problems 
with software should be reported on a Software 
Problem Report (SPR) form. 



Did you find errors in this manual? If so, specify by page. 



c 
o 



Did you find this manual understandable, usable, and well-organized? 
Please make suggestions for improvement. 



3 Is there sufficient documentation on associated system programs 

" required for use of the software described in this manual? If not, 

}3 what material is missing and where should it be placed? 



Please indicate the type of user/reader that you most nearly represent. 

|~~| Assembly language programmer 

I I Higher-level language programmer 

I I Occasional programmer (experienced) 

I I User with little programming experience 

I I Student programmer 

I I Non-programmer interested in computer concepts and capabilities 



Name Date 

Organization .^ 

Street — 



City State Zip Code 

or 
Country 

If you require a written reply, please check here. Q 
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